Medical devices and related event pattern treatment recommendation methods

ABSTRACT

Methods, systems, and media for event pattern treatment recommendations are provided. In some embodiments, a method involve identifying a plurality of event patterns within a plurality of monitoring periods based on measurement values of a physiological condition. The techniques may involve causing display of a snapshot graphical user interface display, wherein the snapshot graphical user interface display comprises a graph overlay region and an event detection region, the graph overlay region comprises a graphical representation of the measurement values, and the event detection region comprises a pattern guidance display for at least a subset of the plurality of event patterns, wherein the pattern guidance display for at least one event pattern includes a graphical representation of a recommended therapeutic remedial action that comprises therapy parameters, to be used by a medical device during a subsequent time period, configured to mitigate occurrence of the at least one event pattern.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application is a continuation of U.S. patent application Ser. No.16/058,736, filed Aug. 8, 2018, which is a continuation-in-part of U.S.patent application Ser. No. 15/693,238, filed Aug. 31, 2017, which is acontinuation-in-part of U.S. patent application Ser. No. 15/132,126,filed Apr. 18, 2016, which claims the benefit of U.S. Provisional PatentApplication Ser. No. 62/243,416, filed Oct. 19, 2015, the entirecontents of which are incorporated by reference herein.

TECHNICAL FIELD

Embodiments of the subject matter described herein relate generally tomedical devices, and more particularly, embodiments of the subjectmatter relate to generating reports for therapy management.

BACKGROUND

Infusion pump devices and systems are relatively well known in themedical arts, for use in delivering or dispensing an agent, such asinsulin or another prescribed medication, to a patient. A typicalinfusion pump includes a pump drive system which typically includes asmall motor and drive train components that convert rotational motormotion to a translational displacement of a plunger (or stopper) in areservoir that delivers medication from the reservoir to the body of auser via a fluid path created between the reservoir and the body of auser. Use of infusion pump therapy has been increasing, especially fordelivering insulin for diabetics.

Control schemes have been developed that allow insulin infusion pumps tomonitor and regulate a user's blood glucose level in a substantiallycontinuous and autonomous manner. However, regulating blood glucoselevel is still complicated by variations in the response time for thetype of insulin being used along with variations in a user's individualinsulin response and daily activities (e.g., exercise, carbohydrateconsumption, bolus administration, and the like). Additionally,manually-initiated deliveries of insulin prior to or contemporaneouslywith consuming a meal (e.g., a meal bolus or correction bolus) alsoinfluence the overall glucose regulation, along with variouspatient-specific ratios, factors, or other control parameters.

Physicians have recognized that continuous monitoring provides a greaterunderstanding of a diabetic's condition. That said, there is also aburden imposed on physicians and other healthcare providers to adapt tocontinuous monitoring and incorporate the amount of data obtainedtherefrom in a manner that allows for a physician to meaningfully assistand improve patient outcomes. While automated reports can be generatedbased on the data, they can be difficult to parse or appear overwhelmingto physicians, which given the limited time available to physicians, maydiscourage adoption and incorporation of continuous monitoring as partof their practice. Accordingly, there is a need to generate and provideinformation in a usable form that can be quickly and intuitivelyinterpreted and applied.

BRIEF SUMMARY

Disclosed herein are techniques related to event pattern treatmentrecommendations. The techniques can be practiced using aprocessor-implemented method; a system comprising one or more processorsand one or more processor-readable media; and/or one or morenon-transitory process-readable media.

In some embodiments, the techniques may involve identifying a pluralityof event patterns within a plurality of monitoring periods based onmeasurement values of a physiological condition. The techniques mayinvolve causing display of a snapshot graphical user interface display,wherein the snapshot graphical user interface display comprises a graphoverlay region and an event detection region, the graph overlay regioncomprises a graphical representation of the measurement values withrespect to a time of day, and the event detection region comprises apattern guidance display for at least a subset of the plurality of eventpatterns, wherein the pattern guidance display for at least one eventpattern of the subset of the plurality of event patterns includes agraphical representation of a recommended therapeutic remedial actionthat comprises therapy parameters, to be used by a medical device duringa subsequent time period, configured to mitigate occurrence of the atleast one event pattern during the subsequent time period. Thetechniques may involve causing, responsive to user input, automatedreprogramming of the medical device for implementation of therecommended therapeutic remedial action prior to the subsequent timeperiod.

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the detaileddescription. This summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the subject matter may be derived byreferring to the detailed description and claims when considered inconjunction with the following figures, wherein like reference numbersrefer to similar elements throughout the figures, which may beillustrated for simplicity and clarity and are not necessarily drawn toscale.

FIG. 1 depicts an exemplary embodiment of a snapshot graphical userinterface (GUI) display that may be presented on a display deviceassociated with a computing device in one or more embodiments;

FIG. 2 depicts an exemplary embodiment of a patient management system200 suitable for generating and presenting the snapshot GUI display ofFIG. 1 ;

FIG. 3 is a flow diagram of an exemplary snapshot presentation processsuitable for use with the patient management system of FIG. 2 togenerate a snapshot GUI display in one or more exemplary embodiments;

FIG. 4 is a flow diagram of an exemplary pattern guidance presentationprocess suitable for use with the patient management system of FIG. 2 inconjunction with the snapshot presentation process of FIG. 3 to populatean event pattern detection region of a snapshot GUI display in one ormore exemplary embodiments;

FIG. 5 depicts an embodiment of a computing device for a diabetes datamanagement system in accordance with one or more embodiments;

FIG. 6 depicts an exemplary embodiment of an infusion system;

FIG. 7 depicts a plan view of an exemplary embodiment of a fluidinfusion device suitable for use in the infusion system of FIG. 6 ;

FIG. 8 is an exploded perspective view of the fluid infusion device ofFIG. 7 ;

FIG. 9 is a cross-sectional view of the fluid infusion device of FIGS.7-8 as viewed along line 9-9 in FIG. 8 when assembled with a reservoirinserted in the infusion device;

FIG. 10 is a block diagram of an exemplary control system suitable foruse in a fluid infusion device, such as the fluid infusion device ofFIG. 2, 6 or 7 ;

FIG. 11 is a block diagram of an exemplary pump control system suitablefor use in the control system of FIG. 10 ;

FIG. 12 is a block diagram of a closed-loop control system that may beimplemented or otherwise supported by the pump control system in thefluid infusion device of FIG. 10 in one or more exemplary embodiments;

FIG. 13 is a flow diagram of an exemplary recommendation processsuitable for use with the patient management system of FIG. 2 torecommend remedial actions in conjunction with the snapshot presentationprocess of FIG. 3 or the pattern guidance presentation process of FIG. 4;

FIGS. 14-16 depict exemplary embodiments of snapshot GUI displays thatmay be presented on a display device associated with a computing devicein accordance with one or more embodiments of the recommendation processof FIG. 13 ; and

FIGS. 17-20 depict exemplary embodiments of snapshot GUI displaysincluding expandable and collapsible pattern guidance displays suitablefor presentation on a display device associated with a computing devicein accordance with one or more embodiments.

DETAILED DESCRIPTION

The following detailed description is merely illustrative in nature andis not intended to limit the embodiments of the subject matter or theapplication and uses of such embodiments. As used herein, the word“exemplary” means “serving as an example, instance, or illustration.”Any implementation described herein as exemplary is not necessarily tobe construed as preferred or advantageous over other implementations.Furthermore, there is no intention to be bound by any expressed orimplied theory presented in the preceding technical field, background,brief summary or the following detailed description.

Exemplary embodiments of the subject matter described herein areimplemented in conjunction with medical devices, such as portableelectronic medical devices. Although many different applications arepossible, the following description focuses on embodiments thatincorporate a fluid infusion device (or infusion pump) as part of aninfusion system deployment. For the sake of brevity, conventionaltechniques related to infusion system operation, insulin pump and/orinfusion set operation, and other functional aspects of the systems (andthe individual operating components of the systems) may not be describedin detail here. Examples of infusion pumps may be of the type describedin, but not limited to, U.S. Pat. Nos. 4,562,751; 4,685,903; 5,080,653;5,505,709; 5,097,122; 6,485,465; 6,554,798; 6,558,320; 6,558,351;6,641,533; 6,659,980; 6,752,787; 6,817,990; 6,932,584; and 7,621,893;each of which are herein incorporated by reference. That said, thesubject matter described herein can be utilized more generally in thecontext of overall diabetes management or other physiological conditionsindependent of or without the use of an infusion device or other medicaldevice (e.g., when oral medication is utilized), and the subject matterdescribed herein is not limited to any particular type of medication.

Generally, a fluid infusion device includes a motor or other actuationarrangement that is operable to linearly displace a plunger (or stopper)of a reservoir provided within the fluid infusion device to deliver adosage of fluid, such as insulin, to the body of a user. Dosage commandsthat govern operation of the motor may be generated in an automatedmanner in accordance with the delivery control scheme associated with aparticular operating mode, and the dosage commands may be generated in amanner that is influenced by a current (or most recent) measurement of aphysiological condition in the body of the user. For example, in aclosed-loop operating mode, dosage commands may be generated based on adifference between a current (or most recent) measurement of theinterstitial fluid glucose level in the body of the user and a target(or reference) glucose value. In this regard, the rate of infusion mayvary as the difference between a current measurement value and thetarget measurement value fluctuates. For purposes of explanation, thesubject matter is described herein in the context of the infused fluidbeing insulin for regulating a glucose level of a user (or patient);however, it should be appreciated that many other fluids may beadministered through infusion, and the subject matter described hereinis not necessarily limited to use with insulin.

Exemplary embodiments of the subject matter described herein generallyrelate to systems for analyzing and presenting information pertaining tooperation of the infusion device delivering fluid to a body of a user.In exemplary embodiments, a snapshot graphical user interface (GUI)display is presented on an electronic device, and the snapshot GUIdisplay includes or otherwise provides graphical representations orother graphical indicia of various aspects of the physiologicalcondition in the body of the user that is regulated or otherwiseinfluenced by the fluid delivered by the infusion device. For example,the snapshot GUI display may include graphical representations of adiabetic patient's glucose levels along with other indicia pertaining tothe glycemic control achieved by the infusion device delivering insulinto the patient.

In exemplary embodiments described herein, the snapshot GUI displayincludes a pattern detection region that includes graphical indicia ofevent pattern(s) detected or otherwise identified based on measurementdata for the user's physiological condition. The detected eventpattern(s) are prioritized based on one or more prioritization criteriaand filtered based on one or more filtering criteria, resulting in afiltered prioritized list of detected event patterns that includes onlythose event patterns to be presented to the user. For each retainedevent pattern in the filtered prioritized list, a respective patternguidance display is generated or otherwise provided which includesinformation pertaining to that respective event pattern, such as, forexample, an identification of the type of event pattern, an indicationof a period of time associated with the event pattern, one or moremetric(s) indicative of the frequency and/or severity of the event, andthe like. Additionally, the pattern guidance display includes graphicalindicia of one or more potential causes of event pattern, which, in turnmay be utilized by the patient, the patient's doctor or other healthcare provider, or another individual in assessing the efficacy of theregulation achieved by the infusion device and identifying potentialactions that may improve the quality of control achieved by the infusiondevice. As described in greater detail below in the context of FIGS.13-16 , in one or more embodiments, information pertaining to adisplayed event pattern may be analyzed in connection with othertherapeutic or physiological information associated with the patient toidentify a remedial action that could potentially resolve, mitigate,correct or otherwise address the event pattern (e.g., adding a newmedication, adjusting dosages or delivery rates, and the like) andprovide corresponding graphical indicia of the remedial action inconnection with the displayed event pattern.

Event Pattern Presentation

FIG. 1 depicts an exemplary embodiment of a snapshot GUI display 100 orreport that may be presented on a display device associated with anelectronic device, such as, for example, a computing device, a portablemedical device, a sensor device, or the like. The snapshot GUI display100 includes a plurality of regions 102, 104, 106, 108 that presentinformation pertaining to past operation of a fluid infusion device thatdelivers insulin to regulate the glucose level of a diabetic patient. Aheader region 102 is presented at the top of the snapshot GUI display100 and includes a graphical representation of a preceding time periodof operation (e.g., November 3-November 6) associated with the snapshotGUI display 100 for which information is presented in the below regions104, 106, 108.

A graph overlay region 108 is presented at the bottom of the snapshotGUI display 100 that includes graphical representations of historicalmeasurement data for the patient's glucose level over the snapshot timeperiod with respect to time. In this regard, the graph overlay region108 may include a line graph including a line associated with each daywithin the snapshot time period that depicts the patient's sensorglucose measurements values from that day with respect to time of day.Additionally, the graph overlay region 108 may include a linerepresentative of the average of the patient's sensor glucosemeasurements across the different days within the snapshot time periodwith respect to time of day. The illustrated graph overlay region 108also includes a visually distinguishable overlay region that indicates atarget range for the patient's sensor glucose measurement values. Inexemplary embodiments, the graphical representation of the measurementsfor each different day or date depicted on the graph overlay region 108is rendered with a unique color or other visually distinguishablecharacteristic relative to the graphical representations correspondingto other days or dates, with the meal markers on that respective day ordate also being rendered in the same color or visually distinguishablecharacteristic and placed on the line corresponding to that respectiveday or date. The illustrated graph overlay region 108 also includesgraphical representations of multiday averages of the measurement datafor different periods or times of day, for example, every three-hoursegment of the day (e.g., the average sensor glucose measurement for the12 AM-3 AM time period across the dates encompassed by the snapshot timeperiod is 189 mg/dL).

A performance metric region 104 is presented below the header region 102and includes graphical representations or other indicia of the valuesfor various performance metrics calculated based on the historicalmeasurement data for the patient's glucose level over the time periodassociated with the snapshot GUI display 100. The performance metricsdepicted in the performance metric region 104 may include an averagesensor glucose measurement value for the patient calculated based on thesensor glucose measurement values over the snapshot time period, anestimated A1C level calculated based on the sensor glucose measurementvalues over the snapshot time period, and estimated percentages of thesnapshot time period during which durations the sensor glucosemeasurement values were above an upper glucose threshold value (e.g.,150 mg/dL), below a lower glucose threshold value (e.g., 70 mg/dL), orbetween the upper and lower glucose threshold values. In this regard,the upper and lower glucose threshold values may define a target regionfor the patient's glucose level during the snapshot time period. Thethreshold values defining the target region may be configurable by auser, for example, to vary one or more aspects of the report, oralternatively, to influence the glucose regulation provided by theinfusion device while also influencing one or more aspects of thereport. The graphical indicia for performance metrics presented in theperformance metric region 104 may include textual representations of therespective performance metric values along with charts, graphs, or othervisualizations of respective performance metric values. For example, theillustrated embodiment of the performance metric region 104 includesprogress bar GUI elements that depict the respective percentages of thesnapshot time period during which the patient's sensor glucosemeasurement values were above, below, or between upper and lower glucosethreshold values.

Still referring to FIG. 1 , the snapshot GUI display 100 also includes apattern detection region 106 presented between the performance metricregion 104 and the graph overlay region 108. The pattern detectionregion 106 includes a plurality of pattern guidance displays 120, 130,140, where each pattern guidance display 120, 130, 140 corresponds to arespective pattern of events identified during the snapshot time periodbased on the patient's sensor glucose measurement values for thesnapshot time period. In this regard, the historical sensor glucosemeasurement values are analyzed for different monitoring periods withinthe snapshot time period. As described in greater detail below in thecontext of FIG. 3 , based on the subset of sensor glucose measurementvalues associated with times of day within a respective monitoringperiod, a pattern of one or more events is detected or otherwiseidentified within that monitoring period, such as, for example, aglucose variability event, a high glucose (or hyperglycemic) event, or alow glucose (or hypoglycemic) event. After identifying a plurality ofevent patterns within respective monitoring periods, the identifiedevent patterns are prioritized and filtered to limit the number of eventpatterns for display. For example, in one embodiment, the detected eventpatterns are prioritized primarily based on event type (e.g., from mostsignificant to least significant) and secondarily based on themonitoring period associated with the respective event pattern, and thenfiltered to first remove lower priority event patterns having the sameassociated monitoring period as a higher priority event pattern, andthen secondarily remove remaining event patterns above a displaythreshold that limits the number of displayed event patterns. In thisregard, FIG. 1 depicts an embodiment where the variability event type isprioritized above the hypoglycemic event type and the hyperglycemicevent type in that order, and with the display threshold being equal tothree to limit the number of pattern guidance displays within thepattern detection region 106 to three.

As described in greater detail below in the context of FIG. 4 , for eachremaining event pattern of the filtered prioritized list, a patternguidance display 120, 130, 140 is generated that includes a headerregion 122, 132, 142 that includes graphical indicia of the event typeand the monitoring period associated with the detected pattern, asummary region 124, 134, 144 that includes graphical indicia of thenumber, frequency, severity, or other characteristics of the eventsassociated with the detected pattern, and an analysis region 126, 136,146 that includes graphical indicia of potential causes or remedialactions for the detected events. It should be noted that the graphicalindicia of potential causes or remedial actions may also be prioritizedor ordered according to their respective clinical relevance.Additionally, in exemplary embodiments, graphical indicia 128, 138, 148of the detected event patterns are presented within the graph overlyregion 108 in a manner that establishes an association between thedetected event pattern, the time of day associated with itscorresponding monitoring period, and its relative priority level. Thus,the graphical indicia 128, 138, 148 facilitate establishing anassociation between a respective subset of the historical measurementdata presented within the graph overlay region 108 and a correspondingevent pattern detected based on that subset of historical measurementdata. For example, in the illustrated embodiment of FIG. 1 , a marker128 is presented overlying the graph overlay region 108 that includes anidentifier that indicates the detected event pattern the marker 128corresponds to (e.g., number 1 to indicate the highest priority eventpattern 120), and the marker 128 has a width or other dimension thatencompasses or otherwise corresponds to the subset of the sensor glucosemeasurement values associated with the time of day corresponding to themonitoring period associated with the detected event pattern (e.g., thelunch time period).

FIG. 2 depicts an exemplary embodiment of a patient management system200 capable of generating and displaying the snapshot GUI display 100 ofFIG. 1 for review and analysis of a user. The patient management system200 includes an infusion device 202 that is communicatively coupled to asensing arrangement 204 to obtain measurement data indicative of aphysiological condition in the body of a patient, such as sensor glucosemeasurement values as described in greater detail below in the contextof FIGS. 6-12 . In exemplary embodiments, the infusion device 202operates autonomously to regulate the patient's glucose level based onthe sensor glucose measurement values received from the sensingarrangement 204.

In exemplary embodiments, the infusion device 202 periodically uploadsor otherwise transmits the measurement data (e.g., sensor glucosemeasurement values and timestamps associated therewith) to a remotedevice 206 via a communications network 214, such as a wired and/orwireless computer network, a cellular network, a mobile broadbandnetwork, a radio network, or the like. Additionally, in someembodiments, the infusion device 202 also uploads delivery data and/orother information indicative of the amount of fluid delivered by theinfusion device and the timing of fluid delivery, which may include, forexample, information pertaining to the amount and timing ofmanually-initiated boluses and associated meal announcements. Someexamples of an infusion device uploading measurement and delivery datato a remote device are described in United States Patent ApplicationPublication Nos. 2015/0057807 and 2015/0057634, which are incorporatedby reference herein in their entirety.

The remote device 206 is coupled to a database 208 configured to storeor otherwise maintain the historical measurement and delivery datareceived from the infusion device 202 in association with a patientassociated with the infusion device 202 (e.g., using unique patientidentification information). The remote device 206 generally representsa server or another suitable electronic device configured to analyze orotherwise monitor the measurement and delivery data obtained for thepatient associated with the infusion device 202 and generate a snapshotGUI display (e.g., snapshot GUI display 100) that may be presented onthe remote device 206 or another electronic device 210, alternativelyreferred to herein as a client device. In practice, the remote device206 may reside at a location that is physically distinct and/or separatefrom the infusion device 202, such as, for example, at a facility thatis owned and/or operated by or otherwise affiliated with a manufacturerof the infusion device 202. For purposes of explanation, but withoutlimitation, the remote device 206 may alternatively be referred toherein as a server.

In the illustrated embodiment, the server 206 generally represents acomputing system or another combination of processing logic, circuitry,hardware, and/or other components configured to support the processes,tasks, operations, and/or functions described herein. In this regard,the server 206 includes a processing system 216, which may beimplemented using any suitable processing system and/or device, such as,for example, one or more processors, central processing units (CPUs),controllers, microprocessors, microcontrollers, processing cores and/orother hardware computing resources configured to support the operationof the processing system 216 described herein. The processing system 216may include or otherwise access a data storage element 218 (or memory)capable of storing programming instructions for execution by theprocessing system 216, that, when read and executed, cause processingsystem 216 to perform or otherwise support the processes, tasks,operations, and/or functions described herein. For example, in oneembodiment, the instructions cause the processing system 216 to create,generate, or otherwise facilitate an application platform that generatesor otherwise provides instances of a virtual application at run-time (or“on-demand”) based at least in part upon data that is stored orotherwise maintained by the database 208. Depending on the embodiment,the memory 218 may be realized as a random-access memory (RAM), readonly memory (ROM), flash memory, magnetic or optical mass storage, orany other suitable non-transitory short or long-term data storage orother computer-readable media, and/or any suitable combination thereof.

The client device 210 generally represents an electronic device coupledto the network 214 that may be utilized by a user to access and viewdata stored in the database 208 via the server 206. In practice, theclient device 210 can be realized as any sort of personal computer,mobile telephone, tablet or other network-enabled electronic device thatincludes a display device, such as a monitor, screen, or anotherconventional electronic display, capable of graphically presenting dataand/or information provided by the server 206 along with a user inputdevice, such as a keyboard, a mouse, a touchscreen, or the like, capableof receiving input data and/or other information from the user of theclient device 210. A user, such as the patient's doctor or anotherhealthcare provider, manipulates the client device 210 to execute aclient application 212, such as a web browser application, that contactsthe server 206 via the network 214 using a networking protocol, such asthe hypertext transport protocol (HTTP) or the like.

In exemplary embodiments described herein, a user of the client device210 manipulates a user input device associated with the client device210 to input or otherwise provide indication of the patient associatedwith the infusion device 202 along with a period of time for which theuser would like to review, analyze, or otherwise assess measurement dataassociated with the patient. In response, the server 206 accesses thedatabase 208 to retrieve or otherwise obtain historical measurement dataassociated with the identified patient for the identified time periodand generates a snapshot GUI display (e.g., snapshot GUI display 100)that is presented on the display device associated with the clientdevice 210 via the client application 212 executing thereon.

It should be appreciated that FIG. 2 depicts a simplified representationof a patient management system 200 for purposes of explanation and isnot intended to limit the subject matter described herein in any way.For example, in various embodiments, a snapshot GUI display may bepresented on any device within the patient management system 200 (e.g.,the server 206, the infusion device 202, the sensing arrangement 204, orthe like) and not necessarily on the client device 210. Moreover, insome embodiments, the infusion device 202 may be configured to store orotherwise maintain historical measurement and delivery data onboard theinfusion device 202 and generate snapshot GUI displays on a displaydevice associated with the infusion device 202, in which case the server206, the database 208, and the client device 210 may not be present.

FIG. 3 depicts an exemplary snapshot presentation process 300 suitablefor implementation by a patient management system to provide a snapshotGUI display including information pertaining to preceding operation ofan infusion device, such as snapshot GUI display 100 of FIG. 1 . Thevarious tasks performed in connection with the snapshot presentationprocess 300 may be performed by hardware, firmware, software executed byprocessing circuitry, or any combination thereof. For illustrativepurposes, the following description refers to elements mentioned abovein connection with FIG. 2 . In practice, portions of the snapshotpresentation process 300 may be performed by different elements of thepatient management system 200, such as, for example, the infusion device202, the sensing arrangement 204, the server 206, the database 208, theclient device 210, the client application 212, and/or the processingsystem 216. It should be appreciated that the snapshot presentationprocess 300 may include any number of additional or alternative tasks,the tasks need not be performed in the illustrated order and/or thetasks may be performed concurrently, and/or the snapshot presentationprocess 300 may be incorporated into a more comprehensive procedure orprocess having additional functionality not described in detail herein.Moreover, one or more of the tasks shown and described in the context ofFIG. 3 could be omitted from a practical embodiment of the snapshotpresentation process 300 as long as the intended overall functionalityremains intact.

The illustrated snapshot presentation process 300 begins by receiving orotherwise obtaining measurement data for the evaluation period beinganalyzed (task 302). In this regard, in response to receiving indicationof a desired time period for the snapshot GUI display 100, the server206 accesses the database 208 to obtain the patient's sensor measurementvalues having associated timestamps that are within the time period forthe snapshot GUI display 100. For example, for the embodiment of FIG. 1where the snapshot time period corresponds to Nov. 3, 2014 to Nov. 6,2014, the server 206 obtains, from the database 208, the stored sensormeasurement values previously obtained by the sensing arrangement 204having timestamp indicating an associated date from Nov. 3, 2014 to Nov.6, 2014.

After obtaining the measurement data for the evaluation period, thesnapshot presentation process 300 continues by identifying a pluralityof different monitoring periods within the evaluation period,identifying event detection thresholds or other parameters or criteriaused for detecting event patterns based on the measurement data, andthen analyzing the measurement data associated with each of thedifferent monitoring periods with respect to the event detectionthresholds to identify event patterns occurring within the respectivemonitoring periods (tasks 304, 306, 308). In this regard, sensormeasurement values are classified into one or more monitoring periodsbased on the timestamps associated with those values falling within thetime period associated with the respective monitoring period(s), andthen the sensor measurement values within each monitoring period areanalyzed with respect to the various event detection criteria toidentify event patterns associated with the respective monitoringperiod. The sensor measurement values within a monitoring period may becompared to a glucose threshold value to identify a number of times thatthe sensor measurement values violated the glucose threshold valuewithin the monitoring period, and an event pattern detected when thenumber is greater than one. For example, a hypoglycemic (or low glucose)event pattern may be identified when sensor measurement values within amonitoring period are below a lower glucose threshold value (e.g., 70mg/dL) on two or more days within the evaluation period. Similarly, ahyperglycemic (or high glucose) event pattern may be identified whensensor measurement values within a monitoring period are above an upperglucose threshold value (e.g., 150 mg/dL) on two or more days within theevaluation period.

In exemplary embodiments, the different monitoring periods within theevaluation period include an overnight time period, a fasting timeperiod, a breakfast time period, a lunch time period, and a dinner timeperiod. Additionally, in some embodiments, additional monitoring periodsmay be identified relative to other events, such as, for example, mealindications corresponding to a meal bolus. In such embodiments,measurement values within a fixed period of time (e.g., three hours)preceding a meal indication may be associated with a pre-meal monitoringperiod, while measurement values within another fixed period time afterthe meal indication may be associated with a post-meal monitoringperiod. Depending on the embodiment, the monitoring periods may overlap(e.g., some sensor measurement values fall within multiple differentmonitoring periods), or the monitoring periods may be mutually exclusiveso that each sensor measurement value falls within only one of themonitoring periods. Additionally, in some embodiments, the monitoringperiods may be customizable on a patient-specific (or per-patient)basis, with the corresponding end points (e.g., starting and stoppingtimes) or other reference values defining the end points (e.g., theamount of time before/after a meal indication for a pre- or post-mealmonitoring period) for the different monitoring time periods beingstored or otherwise maintained in the database 208 in association withthe patient. The monitoring periods may be customizable on a per-userbasis (e.g., doctor to doctor) in a similar manner, with thecorresponding timing criteria for the different monitoring time periodsbeing stored or otherwise maintained in the database 208 in associationwith the user of the client device 210.

Once the monitoring time periods to be analyzed are identified, theserver 206 classifies or otherwise categorizes the patient's sensorglucose measurement values into the appropriate monitoring time periods,resulting in a subset of the patient's sensor glucose measurement valuesassociated with each respective monitoring time period. Thereafter, foreach monitoring period, the server 206 analyzes that subset of thepatient's sensor glucose measurement values to identify any hypoglycemicor hyperglycemic event patterns associated with that respectivemonitoring period. As described above, the server 206 identifies ahypoglycemic event when one or more of the patient's sensor glucosemeasurement values within that subset are less than a lower glucosethreshold value on at least two different days within the snapshot timeperiod. Similarly, the server 206 identifies a hyperglycemic event whenone or more of the patient's sensor glucose measurement values withinthe subset are greater than an upper glucose threshold value on at leasttwo different days within the snapshot time period.

Additionally, in exemplary embodiments, the server 206 analyzes thesubset of the patient's sensor glucose measurement values for therespective monitoring period to detect or otherwise identify avariability event pattern across multiple days within the snapshot timeperiod. For example, in one embodiment, the server 206 identifies avariability event pattern when one or more the patient's sensor glucosemeasurement values for the monitoring period are less than the lowerglucose threshold value on at least two different days within thesnapshot time period and one or more of the patient's sensor glucosemeasurement values within the subset are greater than an upper glucosethreshold value on at least two different days within the snapshot timeperiod. In exemplary embodiments, the server 206 also calculates aninterquartile range of the daily median sensor glucose measurementvalues within the monitoring period and detects a variability eventpattern when the interquartile range is greater than a variabilitydetection threshold (e.g., 80 mg/dL). It should be noted that theinterquartile range is merely one exemplary way in which a variabilityevent pattern may be detected, and in other embodiments, a variabilityevent pattern may be detected based on other statistics calculated basedon measurement values for a given monitoring period (e.g., standarddeviation values, variance values, or the like).

In a similar manner as described above in the context of the monitoringperiods, the detection threshold values or other detection criteria forevent patterns may be customizable on a patient-specific (orper-patient) basis, with the corresponding detection threshold values(e.g., the lower glucose threshold value, the upper glucose thresholdvalue, the variability detection threshold value, and the lie) beingstored or otherwise maintained in the database 208 in association withthe patient. Additionally or alternatively, in some embodiments, thedetection threshold values or other detection criteria may becustomizable on a per-user basis (e.g., doctor to doctor) in a similarmanner, with the corresponding detection criteria being stored orotherwise maintained in the database 208 in association with the user ofthe client device 210. Thus, the various criteria used for generatingthe event detection region 106 on the snapshot GUI display 100 may varydepending on either the patient being analyzed or the user of the clientdevice 210.

Still referring to FIG. 3 , after identifying event patterns associatedwith the different time periods, the snapshot presentation process 300continues by prioritizing the event patterns according to one or moreprioritization criteria to obtain a prioritized list of detected eventpatterns. In exemplary embodiments, the snapshot presentation process300 prioritizes the event patterns primarily based on event type, andsecondarily based on the monitoring period associated with therespective event patterns (tasks 310, 312). For example, in oneembodiment, the server 206 prioritizes, sorts, or otherwise ordersvariability event patterns ahead of both hypoglycemic and hyperglycemicevent patterns, with hypoglycemic event patterns being prioritized orordered ahead of hyperglycemic event patterns. Thus, prioritization byevent type results in variability event patterns being ordered first ina list or other data structure containing the detected event patterns,followed by hypoglycemic event patterns, followed by the hyperglycemicevent patterns.

Thereafter, the server 206 prioritizes, sorts, or otherwise orders eventpatterns for each event type by their associated monitoring period. Forexample, the server 206 prioritizes, sorts, or otherwise orders thevariability event patterns by monitoring period and orders theprioritized variability event patterns ahead of the hypoglycemic eventpatterns, which are also prioritized or otherwise ordered by monitoringperiod. In one embodiment, the server 206 prioritizes event patterns bymonitoring period in the following order: the fasting time period orpre-breakfast time period, the overnight time period, the breakfast orpost-breakfast time period, the dinner or post-dinner time period, thelunch or post-lunch time period, the pre-dinner time period, and thepre-lunch time period. Thus, in such an embodiment, the event patternsmay be prioritized as follows: a variability event associated with thefasting time period or pre-breakfast time period, a variability eventassociated with the overnight time period, a variability eventassociated with the breakfast or post-breakfast time period, avariability event associated with the dinner or post-dinner time period,a variability event associated with the lunch or post-lunch time period,a variability event associated with the pre-dinner time period, and avariability event associated with the pre-lunch time period, followed bya hypoglycemic event associated with the fasting time period orpre-breakfast time period, a hypoglycemic event associated with theovernight time period, a hypoglycemic event associated with thebreakfast or post-breakfast time period, a hypoglycemic event associatedwith the dinner or post-dinner time period, a hypoglycemic eventassociated with the lunch or post-lunch time period, a hypoglycemicevent associated with the pre-dinner time period, and a hypoglycemicevent associated with the pre-lunch time period, followed by ahyperglycemic event associated with the fasting time period orpre-breakfast time period, a hyperglycemic event associated with theovernight time period, a hyperglycemic event associated with thebreakfast or post-breakfast time period, a hyperglycemic eventassociated with the dinner or post-dinner time period, a hyperglycemicevent associated with the lunch or post-lunch time period, ahyperglycemic event associated with the pre-dinner time period, and ahyperglycemic event associated with the pre-lunch time period.

For example, referring to FIG. 1 , prioritization by monitoring periodresults in a hyperglycemic event pattern detected within a fasting timeperiod being ordered ahead of a hyperglycemic event pattern detectedwithin an overnight time period (e.g., the period of time preceding 5:00AM) in the prioritized list. In this regard, more significant timeperiods for purposes of glycemic control may be preferentially displayedover less significant time periods. For example, since the patient maybe sleeping or waking up and less likely or less capable of respondingto alerts or notifications generated by the infusion device 202, eventsoccurring overnight or early in the morning prior to eating may requiremore attention or remedial action than events occurring during the daywhen the patient is awake and alert and capable of responding to alertsor notifications generated by the infusion device 202.

In a similar manner as described above, the prioritization criteria maybe customizable or otherwise configurable on a per-patient or per-userbasis and such particular prioritization criteria may be stored orotherwise maintained in the database 208 in association with thatpatient or user. Additionally, the ordering of the application of theprioritization criteria may be customizable or configurable. Forexample, in one alternative embodiment, the event patterns areprioritized primarily based on monitoring period and secondarily basedon the event type associated with the respective event patterns.

In exemplary embodiments, after prioritizing the detected eventpatterns, the snapshot presentation process 300 continues by filteringthe event patterns according to one or more filtering criteria to obtaina reduced prioritized list of detected event patterns for presentationon the snapshot GUI display. In exemplary embodiments, the snapshotpresentation process 300 filters the prioritized list of detected eventpatterns first by event type priority within the respective monitoringperiods to remove or exclude lower priority event patterns and therebyselect or retain only the highest priority event pattern detected foreach respective monitoring period (task 314). For example, if ahypoglycemic event pattern (e.g., sensor measurement values below alower threshold value on at least two days), a hyperglycemic eventpattern (e.g., sensor measurement values above an upper threshold valueon at least two days), and a variability event pattern (e.g., sensormeasurement values above an upper threshold value on at least two daysand below a lower threshold value on at least two days) are all detectedwithin a particular monitoring period, the server 206 may remove thehypoglycemic event pattern and the hyperglycemic event patternassociated with that monitoring period from the prioritized list ofdetected event patterns when the variability event type has the highestpriority, so that the list retains only the variability event patternassociated with the monitoring period. In this regard, since remedialactions that may be taken by the patient or user to mitigate orotherwise address the highest priority event pattern may also influencethe lower priority event patterns, removing lower priority eventpatterns allows the patient or user to focus on addressing moresignificant event patterns, which, in turn, could also result in otherevent patterns detected within that monitoring period being resolved. Asnoted above, the event type priorities may be customizable or otherwiseconfigurable on a per-patient or per-user basis, such that particularprioritization criteria may be stored or otherwise maintained in thedatabase 208 in association with that patient or user and the resultingtypes of events preferentially presented within the pattern detectionregion of the snapshot GUI display may vary depending on the user orpatient.

After the filtering the prioritized list of detected event patterns byevent type priority within the respective monitoring periods, theresulting list includes only one event pattern for each monitoringperiod during which an event pattern was detected, with the retainedevent pattern for a respective monitoring period being the highestpriority event pattern within that monitoring period. For example,referring to the embodiment of FIG. 1 , when the server 206 identifies avariability event pattern and a hypoglycemic and/or hyperglycemic eventpattern within the lunch time monitoring period, only the variabilityevent pattern associated with the lunch time period may remain in theprioritized list after filtering the lower priority event patternsdetected within the lunch time period. Similarly, if the server 206identified both a hypoglycemic event pattern and a hyperglycemic eventpattern within the pre-dinner time period, only the hypoglycemic eventpattern associated with the pre-dinner time period may remain in theprioritized list.

Still referring to FIG. 3 , in exemplary embodiments, after filtering byevent type priority within the respective monitoring periods, thesnapshot presentation process 300 continues by filtering the list ofevent patterns based on a display threshold number of event patterns toremove or exclude lower priority event patterns and thereby select orretain only a limited number of the highest priority event patterns forpresentation on the snapshot GUI display (task 316). For example, in theembodiment of FIG. 1 , the display threshold number is equal to three,so that all event patterns after the first three event patterns in theprioritized list are removed or otherwise excluded, resulting in afiltered prioritized list that includes only the three highest priorityevent patterns remaining after filtering by event type priority withinthe respective monitoring periods. Thus, the hyperglycemic event patterndetected for an overnight monitoring period (e.g., the time periodpreceding the fasting monitoring period) may be filtered or otherwiseremoved from the list based on the fasting monitoring period beingprioritized over the overnight monitoring period (e.g., task 312).Again, it should be noted that the display threshold number may becustomizable or otherwise configurable on a per-patient or per-userbasis, so that the number of pattern guidance displays presented withinthe pattern detection region of the snapshot GUI display may varydepending on the user or patient.

The snapshot presentation process 300 continues by generating orotherwise providing pattern guidance displays for the remaining eventpatterns in the filtered prioritized list within the snapshot GUIdisplay along with corresponding indicia for the event patterns on thegraph overlay region of the snapshot GUI display (tasks 318, 320). Inexemplary embodiments, the pattern guidance displays are presented in amanner such that higher priority event patterns are preferentiallydisplayed relative to lower priority event patterns, for example, bypresenting the highest priority remaining event pattern above and/or tothe left of the other remaining event patterns and presenting the lowestpriority remaining event pattern below and/or to the right of the otherremaining event patterns. The indicia for the remaining event patternspresented on the graph overlay region identify or otherwise indicate therelative priority of the detected event pattern along with thecorresponding monitoring period relative to the time period depicted onthe graph.

Referring to FIG. 1 , prioritization by event type (e.g., task 310) andthen by monitoring period (e.g., task 312) results in the variabilityevent pattern detected within the lunch time period being ordered firstin the prioritized list, followed by a hypoglycemic event patterndetected within the lunch time period, followed by a hypoglycemic eventpattern detected within a pre-dinner time period, followed by ahyperglycemic event pattern detected within a fasting time period,followed by a hyperglycemic event pattern detected within an overnighttime period, followed by a hyperglycemic event pattern detected within adinner or post-dinner time period. Thereafter, filtering by event typepriority within monitoring period (e.g., task 314) removes the lunchtime hypoglycemic event pattern from the prioritized list, and filteringbased on the display threshold (e.g., task 316) removes the overnighthyperglycemic event pattern and the dinner or post-dinner hyperglycemicevent pattern, resulting in a filtered prioritized list of three eventpatterns that includes the lunch time variability event pattern, thepre-dinner hypoglycemic event pattern, and the fasting hyperglycemicevent pattern.

The server 206 generates or otherwise provides (e.g., on or to theclient application 212 on the client device 210) a pattern guidancedisplay 120 associated with the lunch time variability event patternthat is preferentially displayed relative to (e.g., to the left of) thepattern guidance displays 130, 140 associated with the pre-dinnerhypoglycemic event pattern and the fasting hyperglycemic event pattern,with the pre-dinner hypoglycemic guidance display 130 beingpreferentially displayed relative to the fasting hyperglycemic guidancedisplay 140. As described above, the server 206 generates a marker 128associated with the lunch time variability guidance display 120 having aposition and dimension that encompasses, overlaps, or otherwiseindicates the lunch time monitoring period that also includes anindication (e.g., the number 1) that the event pattern associated withthe lunch time monitoring period is the highest priority event patterndetected. Similarly, the server 206 generates a second marker 138 havinga position and dimension that encompasses, overlaps, or otherwiseindicates the pre-dinner monitoring period and includes an indication(e.g., the number 2) that the event pattern associated with thepre-dinner monitoring period is the second highest priority eventpattern detected, and the server 206 generates a third marker 148 havinga position and dimension that encompasses, overlaps, or otherwiseindicates the fasting monitoring period and includes an indication(e.g., the number 3) that the event pattern associated with the fastingmonitoring period is the third highest priority event pattern detected.

FIG. 4 depicts an exemplary pattern guidance presentation process 400suitable for implementation in conjunction with the snapshotpresentation process 300 of FIG. 3 to generate pattern guidance displayswithin a pattern detection region of a snapshot GUI display, such aspattern guidance displays 120, 130, 140 within pattern detection region106 of the snapshot GUI display 100 of FIG. 1 . The various tasksperformed in connection with the pattern guidance presentation process400 may be performed by hardware, firmware, software executed byprocessing circuitry, or any combination thereof. For illustrativepurposes, the following description refers to elements mentioned abovein connection with FIG. 2 . In practice, portions of the patternguidance presentation process 400 may be performed by different elementsof the patient management system 200; however, for purposes ofexplanation, the subject matter may be described in the context of theguidance presentation process 400 being performed by the server 206. Itshould be appreciated that the pattern guidance presentation process 400may include any number of additional or alternative tasks, the tasksneed not be performed in the illustrated order and/or the tasks may beperformed concurrently, and/or the pattern guidance presentation process400 may be incorporated into a more comprehensive procedure or processhaving additional functionality not described in detail herein.Moreover, one or more of the tasks shown and described in the context ofFIG. 4 could be omitted from a practical embodiment of the patternguidance presentation process 400 as long as the intended overallfunctionality remains intact.

In exemplary embodiments, the pattern guidance presentation process 400is performed for each detected event pattern that remains in thefiltered prioritized list (e.g., task 318) to populate the patterndetection region on a snapshot GUI display. The illustrated process 400generates a header for the pattern guidance display based on the eventtype and monitoring period associated with the detected event patternalong with the priority of the detected event pattern in the filteredprioritized list (task 402). In this regard, the pattern guidance headeridentifies the type of event pattern that was detected, the monitoringperiod that event pattern was detected within, and the priority levelassociated with that event pattern based on the prioritization criteria.For example, referring to FIG. 1 , the server 206 generates a headerregion 122 for the first guidance display 120 within the event patternregion 106 that identifies the first event pattern is a variabilityevent with respect to the patient's sensor glucose values (e.g.,“Variable SG”) and that the event pattern was detected within a lunchtime monitoring period, with the number one indicating the lunch timevariability event is the highest priority event pattern detected.Similarly, the server 206 generates a header region 132 for the secondguidance display 130 that identifies the second event pattern is ahypoglycemic event with respect to the patient's sensor glucose values(e.g., “Low SG”) and that the event pattern was detected within apre-dinner monitoring period, with the number two indicating thepre-dinner hypoglycemic event is the second highest priority eventpattern detected. The server 206 also generates a header region 142 forthe third guidance display 140 that identifies the third event patternis a hyperglycemic event with respect to the patient's sensor glucosevalues (e.g., “High SG”) and that the event pattern was detected withina fasting monitoring period, with the number three indicating thefasting hyperglycemic event is the third highest priority event patterndetected.

In exemplary embodiments, the guidance presentation process 400 alsogenerates a graphical representation of the time of day corresponding tothe respective monitoring periods associated with the displayed eventpatterns (task 404). In this manner, the time of day corresponding to aparticular named monitoring period and the relationship between sensorglucose measurement values and that monitoring period may be madeapparent to the user in conjunction with the markers 128, 138, 148presented on the graph overlay region 108. For a monitoring perioddefined or otherwise referenced from another event or time (e.g., a mealannouncement or maker), the server 206 may calculate or otherwisedetermine the end points for the current instance of that monitoringperiod within the current snapshot time period and provide graphicalrepresentation of that time period encompassing the period between thoseend points within the respective header region. For example, in FIG. 1 ,the time of day associated with the current instance of the pre-dinnermonitoring period associated with pattern guidance display 130 could becalculated or otherwise determined based on respective timings of mealannouncements or markers during the current snapshot time perioddepicted in the graph overlay region 108 that occur in the evening,while accounting for any offset values that are stored in the database208 in association with the current patient or user and define theboundaries of the pre-dinner monitoring period relative to those mealannouncements. That said, default time period end points may also beused in the absence of sufficient meal announcements within a designateddinner time period (e.g., which could also be defined by default endpoint values or be customizable). For other monitoring periods, theserver 206 may obtain the stored end points associated with thatmonitoring period in the database 208 for the current patient or user,and provide a graphical representation of the monitoring period time ofday.

In the illustrated embodiment, the server 206 generates a graphicalrepresentation of the time of day associated with the lunch monitoringperiod (e.g., 11:00 AM-3:00 PM predefined lunch time period sinceinsufficient evening meal announcements exist within that timeframe forcalculating based on meal announcement timings) in the first headerregion 122, a graphical representation of the time of day associatedwith the pre-dinner monitoring period (e.g., the 5:00 PM-8:00 PMpredefined time period since insufficient evening meal announcementsexist within that timeframe for calculating based on meal announcementtimings) in the second header region 132, and a graphical representationof the time of day associated with the fasting monitoring period (e.g.,5:00 AM-7:00 AM) in the third header region 142. As illustrated, theheader may include a footnote symbol or other indicia that indicateswhether a monitoring period capable of being adaptively and dynamicallycalculated based on meal announcements was able to be determined, and ifnot, provide indication that a fixed time of day is utilized due toinsufficient meal announcements within a default timeframe (orpredefined range of time) associated with that respective monitoringperiod.

Still referring to FIG. 4 , the guidance presentation process 400 alsogenerates a graphical representation of one or more characteristicssummarizing, quantifying or otherwise describing the nature of thedisplayed event patterns, such as, for example, the severity, frequency,intensity, or the like (task 406). Thus, a user may quickly ascertainthe relative significance or impact of the individual events thatresulted in the detected event pattern with respect to the patient'sphysiological condition during the snapshot time period in conjunctionwith the relative priority of that event pattern. It should be notedthat any number of different characteristics or metrics that summarize,quantify or otherwise describe the nature of a detected event pattern orthe individual component events of the event pattern may be determinedand presented, and the subject matter is not intended to be limited toany particular characteristics or metric presented in a pattern guidancedisplay.

For example, for a variability event pattern associated with a givenmonitoring period, the number of days that a variability event wasdetected within that monitoring period may be determined and presented,thereby providing indication of the frequency or regularity of thevariability event. For example, in the embodiment of FIG. 1 , based onthe sensor glucose measurement values corresponding to the lunch timemonitoring period, the server 206 may calculate or otherwise determinethat a variability event occurred on four different days within thesnapshot time period and provide a graphical representation of thevariability event frequency within an event pattern summary region 124of the pattern guidance display 120 beneath the header region 122. Inthis example, a user may readily identify that the variability event isthe highest priority event pattern detected within the snapshot timeperiod while also identifying the occurrence of a variability event atduring the lunch time period on every day of the snapshot time period,and thereby be apprised of the relative importance of addressing thelunch time variability event.

For low or high glucose event patterns, the number of days the sensorglucose measurement values violated one or more thresholds within thatmonitoring period or otherwise fell within distinct ranges ofmeasurement values may also be determined and presented. For example, inthe embodiment of FIG. 1 , based on the sensor glucose measurementvalues corresponding to the pre-dinner monitoring period, the server 206may calculate or otherwise determine the number of days within thesnapshot time period that the sensor glucose measurement values werewithin the range between a hypoglycemic glucose threshold (e.g., 50mg/dL) and a lower glucose target range threshold (e.g., 70 mg/dL) andprovide a corresponding graphical representation of the lower severityhypoglycemic event frequency within an event pattern summary region 134of the pattern guidance display 130, while also determining the numberof days within the snapshot time period that those sensor glucosemeasurement values were below the hypoglycemic glucose threshold andprovide a corresponding graphical representation of the higher severityhypoglycemic event frequency within the event pattern summary region134. Similarly, the server 206 may calculate or otherwise determine,based on the sensor glucose measurement values corresponding to thefasting monitoring period, the number of days within the snapshot timeperiod that the sensor glucose measurement values were within the rangebetween an upper target range threshold (e.g., 150 mg/dL) and ahyperglycemic glucose threshold (e.g., 250 mg/dL) and provide acorresponding graphical representation of the lower severityhyperglycemic event frequency within event pattern summary region 144,while also determining the number of days within the snapshot timeperiod that those sensor glucose measurement values were above thehyperglycemic glucose threshold and provide a corresponding graphicalrepresentation of the higher severity hyperglycemic event frequencywithin the event pattern summary region 144.

Referring again to FIG. 4 , the guidance presentation process 400 alsogenerates a graphical representation of one or more potential causes forthe detected event pattern within the pattern guidance display (task408). In this regard, the potential causes may be stored or otherwisemaintained in the database 208 in association with the particularcombination of event type and monitoring period (or time of day), withthe server 206 retrieving or otherwise obtaining the appropriatepotential causes that correspond to the current combination of eventtype and monitoring period presented on the snapshot display. Forexample, to populate the event pattern analysis region 126 of thepattern guidance display 120, the server 206 accesses the database 208to identify the list of potential causes associated with the variabilityevent type that are also associated with the lunch time monitoringperiod (or a time of day between 11:00 AM and 3:00 PM) and thengenerates or otherwise provides a graphical representation of that listof causes in the analysis region 126. In some embodiments, the potentialcauses may be phrased in a manner that suggests remedial actions thatcan be taken to resolve or correct the event pattern. In otherembodiments described in greater detail below in the context of FIGS.13-16 , potential remedial actions (or corresponding logic rules fordetermining such remedial actions) may also be stored or otherwisemaintained in the database 208 in association with the particularcombination of event type and monitoring period (or time of day). Insuch embodiments, the server 206 may identify or otherwise determine theappropriate potential remedial actions (or logical rules therefor) thatcorrespond to the current combination of event type and monitoringperiod presented on the snapshot display and then generate graphicalrepresentations of those remedial actions within the event patternanalysis region 126, 136, 146.

Referring to FIGS. 1-4 , by virtue of the subject matter describedabove, a user may quickly ascertain or otherwise identify the mostsignificant event patterns detected within a particular time periodbeing evaluated on the snapshot GUI display 100, while also being ableto quickly ascertain the relative impact or significance of theconstituent events with respect to the patient's glycemic control, thetemporal characteristics or significance of those events, and thepotential causes or remedial actions for those events at the times ofday during which they were detected. This is particularly useful in thecontext of a patient management system, such as patient managementsystem 200 of FIG. 2 , where the doctor or other medical professional orhealthcare provider monitoring the glycemic control of the patientassociated with the infusion device 202 utilizes a client device 210 toaccess and review historical data associated with the patient over aselect period of time from the database 208 via the server 206. Inexemplary embodiments, the server 206 generates or otherwise provides asnapshot GUI display 100 within a client application 212 on the clientdevice 210 that includes pattern guidance displays 120, 130, 140associated with the highest priority event patterns detected based onthe patient's historical measurement data within the desired evaluationperiod in conjunction with a performance metric region 104 and graphoverlay region 108 that also reflect the patient's historicalmeasurement data within the desired evaluation period. As a result, thesnapshot GUI display 100 allows the user of the client device 210 toquickly assess the general characteristics or nature of the glycemiccontrol for the patient achieved by the infusion device 202, while alsoapprising the user of the most notable event patterns detected withinthe desired evaluation period, their relative significance or impact,and their potential causes or remedies. Thus, the snapshot GUI display100 can aid a doctor or other care provider seeking to integratecontinuous glucose monitoring and/or other autonomous glucose regulationby the infusion device 202 into his or her practice in an efficientmanner by detecting, prioritizing, filtering, and characterizing eventpatterns automatically (e.g., without requiring manual input oranalysis). This, in turn, facilitates improved patient outcomes.

Diabetes Data Management System Overview

FIG. 5 illustrates a computing device 500 including a display 533suitable for presenting a snapshot GUI display 100 as part of a diabetesdata management system in conjunction with the processes 300, 400 ofFIGS. 3-4 described above. The diabetes data management system (DDMS)may be referred to as the Medtronic MiniMed CARELINK™ system or as amedical data management system (MDMS) in some embodiments. The DDMS maybe housed on a server or a plurality of servers which a user or a healthcare professional may access via a communications network via theInternet or the World Wide Web. Some models of the DDMS, which isdescribed as an MDMS, are described in U.S. Patent ApplicationPublication Nos. 2006/0031094 and 2013/0338630, which is hereinincorporated by reference in their entirety.

While description of embodiments may be made in regard to monitoringmedical or biological conditions for subjects having diabetes, thesystems and processes herein are applicable to monitoring medical orbiological conditions for cardiac subjects, cancer subjects, HIVsubjects, subjects with other disease, infection, or controllableconditions, or various combinations thereof.

In embodiments of the invention, the DDMS may be installed in acomputing device in a health care provider's office, such as a doctor'soffice, a nurse's office, a clinic, an emergency room, an urgent careoffice. Health care providers may be reluctant to utilize a system wheretheir confidential patient data is to be stored in a computing devicesuch as a server on the Internet.

The DDMS may be installed on a computing device 500. The computingdevice 500 may be coupled to a display 533. In some embodiments, thecomputing device 500 may be in a physical device separate from thedisplay (such as in a personal computer, a mini-computer, etc.) In someembodiments, the computing device 500 may be in a single physicalenclosure or device with the display 533 such as a laptop where thedisplay 533 is integrated into the computing device. In embodiments ofthe invention, the computing device 500 hosting the DDMS may be, but isnot limited to, a desktop computer, a laptop computer, a server, anetwork computer, a personal digital assistant (PDA), a portabletelephone including computer functions, a pager with a large visibledisplay, an insulin pump including a display, a glucose sensor includinga display, a glucose meter including a display, and/or a combinationinsulin pump/glucose sensor having a display. The computing device mayalso be an insulin pump coupled to a display, a glucose meter coupled toa display, or a glucose sensor coupled to a display. The computingdevice 500 may also be a server located on the Internet that isaccessible via a browser installed on a laptop computer, desktopcomputer, a network computer, or a PDA. The computing device 500 mayalso be a server located in a doctor's office that is accessible via abrowser installed on a portable computing device, e.g., laptop, PDA,network computer, portable phone, which has wireless capabilities andcan communicate via one of the wireless communication protocols such asBluetooth and IEEE 802.11 protocols.

In the embodiment shown in FIG. 5 , the data management system 516comprises a group of interrelated software modules or layers thatspecialize in different tasks. The system software includes a devicecommunication layer 524, a data parsing layer 526, a database layer 528,database storage devices 529, a reporting layer 530, a graph displaylayer 531, and a user interface layer 532. The diabetes data managementsystem may communicate with a plurality of subject support devices 512,two of which are illustrated in FIG. 5 . Although the differentreference numerals refer to a number of layers, (e.g., a devicecommunication layer, a data parsing layer, a database layer), each layermay include a single software module or a plurality of software modules.For example, the device communications layer 524 may include a number ofinteracting software modules, libraries, etc. In embodiments of theinvention, the data management system 516 may be installed onto anon-volatile storage area (memory such as flash memory, hard disk,removable hard, DVD-RW, CD-RW) of the computing device 500. If the datamanagement system 516 is selected or initiated, the system 516 may beloaded into a volatile storage (memory such as DRAM, SRAM, RAM, DDRAM)for execution.

The device communication layer 524 is responsible for interfacing withat least one, and, in further embodiments, to a plurality of differenttypes of subject support devices 512, such as, for example, bloodglucose meters, glucose sensors/monitors, or an infusion pump. In oneembodiment, the device communication layer 524 may be configured tocommunicate with a single type of subject support device 512. However,in more comprehensive embodiments, the device communication layer 524 isconfigured to communicate with multiple different types of subjectsupport devices 512, such as devices made from multiple differentmanufacturers, multiple different models from a particular manufacturerand/or multiple different devices that provide different functions (suchas infusion functions, sensing functions, metering functions,communication functions, user interface functions, or combinationsthereof). By providing an ability to interface with multiple differenttypes of subject support devices 512, the diabetes data managementsystem 516 may collect data from a significantly greater number ofdiscrete sources. Such embodiments may provide expanded and improveddata analysis capabilities by including a greater number of subjects andgroups of subjects in statistical or other forms of analysis that canbenefit from larger amounts of sample data and/or greater diversity insample data, and, thereby, improve capabilities of determiningappropriate treatment parameters, diagnostics, or the like.

The device communication layer 524 allows the DDMS 516 to receiveinformation from and transmit information to or from each subjectsupport device 512 in the system 516. Depending upon the embodiment andcontext of use, the type of information that may be communicated betweenthe system 516 and device 512 may include, but is not limited to, data,programs, updated software, education materials, warning messages,notifications, device settings, therapy parameters, or the like. Thedevice communication layer 524 may include suitable routines fordetecting the type of subject support device 512 in communication withthe system 516 and implementing appropriate communication protocols forthat type of device 512. Alternatively, or in addition, the subjectsupport device 512 may communicate information in packets or other dataarrangements, where the communication includes a preamble or otherportion that includes device identification information for identifyingthe type of the subject support device. Alternatively, or in addition,the subject support device 512 may include suitable user-operableinterfaces for allowing a user to enter information, such as byselecting an optional icon or text or other device identifier thatcorresponds to the type of subject support device used by that user.Such information may be communicated to the system 516, through anetwork connection. In yet further embodiments, the system 516 maydetect the type of subject support device 512 it is communicating within the manner described above and then may send a message requiring theuser to verify that the system 516 properly detected the type of subjectsupport device being used by the user. For systems 516 that are capableof communicating with multiple different types of subject supportdevices 512, the device communication layer 524 may be capable ofimplementing multiple different communication protocols and selects aprotocol that is appropriate for the detected type of subject supportdevice.

The data-parsing layer 526 is responsible for validating the integrityof device data received and for inputting it correctly into a database529. A cyclic redundancy check (CRC) process for checking the integrityof the received data may be employed. Alternatively, or in addition,data may be received in packets or other data arrangements, wherepreambles or other portions of the data include device typeidentification information. Such preambles or other portions of thereceived data may further include device serial numbers or otheridentification information that may be used for validating theauthenticity of the received information. In such embodiments, thesystem 516 may compare received identification information withpre-stored information to evaluate whether the received information isfrom a valid source.

The database layer 528 may include a centralized database repositorythat is responsible for warehousing and archiving stored data in anorganized format for later access, and retrieval. The database layer 528operates with one or more data storage device(s) 529 suitable forstoring and providing access to data in the manner described herein.Such data storage device(s) 529 may comprise, for example, one or morehard discs, optical discs, tapes, digital libraries or other suitabledigital or analog storage media and associated drive devices, drivearrays or the like.

Data may be stored and archived for various purposes, depending upon theembodiment and environment of use. Information regarding specificsubjects and patient support devices may be stored and archived and madeavailable to those specific subjects, their authorized healthcareproviders and/or authorized healthcare payor entities for analyzing thesubject's condition. Also, certain information regarding groups ofsubjects or groups of subject support devices may be made available moregenerally for healthcare providers, subjects, personnel of the entityadministering the system 516 or other entities, for analyzing group dataor other forms of conglomerate data.

Embodiments of the database layer 528 and other components of the system516 may employ suitable data security measures for securing personalmedical information of subjects, while also allowing non-personalmedical information to be more generally available for analysis.Embodiments may be configured for compliance with suitable governmentregulations, industry standards, policies or the like, including, butnot limited to the Health Insurance Portability and Accountability Actof 1996 (HIPAA).

The database layer 528 may be configured to limit access of each user totypes of information pre-authorized for that user. For example, asubject may be allowed access to his or her individual medicalinformation (with individual identifiers) stored by the database layer528, but not allowed access to other subject's individual medicalinformation (with individual identifiers). Similarly, a subject'sauthorized healthcare provider or payor entity may be provided access tosome or all of the subject's individual medical information (withindividual identifiers) stored by the database layer 528, but notallowed access to another individual's personal information. Also, anoperator or administrator-user (on a separate computer communicatingwith the computing device 500) may be provided access to some or allsubject information, depending upon the role of the operator oradministrator. On the other hand, a subject, healthcare provider,operator, administrator or other entity, may be authorized to accessgeneral information of unidentified individuals, groups or conglomerates(without individual identifiers) stored by the database layer 528 in thedata storage devices 529.

In embodiments of the invention, the database layer 528 may storepreference profiles. In the database layer 528, for example, each usermay store information regarding specific parameters that correspond tothe user. Illustratively, these parameters could include target bloodglucose or sensor glucose levels, what type of equipment the usersutilize (insulin pump, glucose sensor, blood glucose meter, etc.) andcould be stored in a record, a file, or a memory location in the datastorage device(s) 529 in the database layer. As described above,preference profiles may include various threshold values, monitoringperiod values, prioritization criteria, filtering criteria, and/or otheruser-specific values for parameters utilized by the processes 300, 400described above to generate a snapshot GUI display, such as snapshot GUIdisplay 100, on the display 533 or a support device 512 in apersonalized or patient-specific manner.

The DDMS 516 may measure, analyze, and track either blood glucose (BG)or sensor glucose (SG) readings for a user. In embodiments of theinvention, the medical data management system may measure, track, oranalyze both BG and SG readings for the user. Accordingly, althoughcertain reports may mention or illustrate BG or SG only, the reports maymonitor and display results for the other one of the glucose readings orfor both of the glucose readings.

The reporting layer 530 may include a report wizard program that pullsdata from selected locations in the database 529 and generates reportinformation from the desired parameters of interest. The reporting layer530 may be configured to generate multiple different types of reports,each having different information and/or showing information indifferent formats (arrangements or styles), where the type of report maybe selectable by the user. A plurality of pre-set types of report (withpre-defined types of content and format) may be available and selectableby a user. At least some of the pre-set types of reports may be common,industry standard report types with which many healthcare providersshould be familiar. In exemplary embodiments described herein, thereporting layer 530 also facilitates generation of a snapshot reportincluding a snapshot GUI display, such as snapshot GUI display 100 ofFIG. 1 .

In embodiments of the invention, the database layer 528 may calculatevalues for various medical information that is to be displayed on thereports generated by the report or reporting layer 530. For example, thedatabase layer 528 may calculate average blood glucose or sensor glucosereadings for specified timeframes. In embodiments of the invention, thereporting layer 530 may calculate values for medical or physicalinformation that is to be displayed on the reports. For example, a usermay select parameters which are then utilized by the reporting layer 530to generate medical information values corresponding to the selectedparameters. In other embodiments of the invention, the user may select aparameter profile that previously existed in the database layer 528.

Alternatively, or in addition, the report wizard may allow a user todesign a custom type of report. For example, the report wizard may allowa user to define and input parameters (such as parameters specifying thetype of content data, the time period of such data, the format of thereport, or the like) and may select data from the database and arrangethe data in a printable or displayable arrangement, based on theuser-defined parameters. In further embodiments, the report wizard mayinterface with or provide data for use by other programs that may beavailable to users, such as common report generating, formatting orstatistical analysis programs. In this manner, users may import datafrom the system 516 into further reporting tools familiar to the user.The reporting layer 530 may generate reports in displayable form toallow a user to view reports on a standard display device, printableform to allow a user to print reports on standard printers, or othersuitable forms for access by a user. Embodiments may operate withconventional file format schemes for simplifying storing, printing andtransmitting functions, including, but not limited to PDF, JPEG, or thelike. Illustratively, a user may select a type of report and parametersfor the report and the reporting layer 530 may create the report in aPDF format. A PDF plug-in may be initiated to help create the report andalso to allow the user to view the report. Under these operatingconditions, the user may print the report utilizing the PDF plug-in. Incertain embodiments in which security measures are implemented, forexample, to meet government regulations, industry standards or policiesthat restrict communication of subject's personal information, some orall reports may be generated in a form (or with suitable softwarecontrols) to inhibit printing, or electronic transfer (such as anon-printable and/or non-capable format). In yet further embodiments,the system 516 may allow a user generating a report to designate thereport as non-printable and/or non-transferable, whereby the system 516will provide the report in a form that inhibits printing and/orelectronic transfer.

The reporting layer 530 may transfer selected reports to the graphdisplay layer 531. The graph display layer 531 receives informationregarding the selected reports and converts the data into a format thatcan be displayed or shown on a display 533.

In embodiments of the invention, the reporting layer 530 may store anumber of the user's parameters. Illustratively, the reporting layer 530may store the type of carbohydrate units, a blood glucose movement orsensor glucose reading, a carbohydrate conversion factor, and timeframesfor specific types of reports. These examples are meant to beillustrative and not limiting.

Data analysis and presentations of the reported information may beemployed to develop and support diagnostic and therapeutic parameters.Where information on the report relates to an individual subject, thediagnostic and therapeutic parameters may be used to assess the healthstatus and relative well-being of that subject, assess the subject'scompliance to a therapy, as well as to develop or modify treatment forthe subject and assess the subject's behaviors that affect his/hertherapy. Where information on the report relates to groups of subjectsor conglomerates of data, the diagnostic and therapeutic parameters maybe used to assess the health status and relative well-being of groups ofsubjects with similar medical conditions, such as, but not limited to,diabetic subjects, cardiac subjects, diabetic subjects having aparticular type of diabetes or cardiac condition, subjects of aparticular age, sex or other demographic group, subjects with conditionsthat influence therapeutic decisions such as but not limited topregnancy, obesity, hypoglycemic unawareness, learning disorders,limited ability to care for self, various levels of insulin resistance,combinations thereof, or the like.

The user interface layer 532 supports interactions with the end user,for example, for user login and data access, software navigation, datainput, user selection of desired report types and the display ofselected information. Users may also input parameters to be utilized inthe selected reports via the user interface layer 532. Examples of usersinclude but are not limited to: healthcare providers, healthcare payerentities, system operators or administrators, researchers, businessentities, healthcare institutions and organizations, or the like,depending upon the service being provided by the system and dependingupon the invention embodiment. More comprehensive embodiments arecapable of interacting with some or all of the above-noted types ofusers, wherein different types of users have access to differentservices or data or different levels of services or data.

In an example embodiment, the user interface layer 532 provides one ormore websites accessible by users on the Internet. The user interfacelayer may include or operate with at least one (or multiple) suitablenetwork server(s) to provide the website(s) over the Internet and toallow access, world-wide, from Internet-connected computers usingstandard Internet browser software. The website(s) may be accessed byvarious types of users, including but not limited to subjects,healthcare providers, researchers, business entities, healthcareinstitutions and organizations, payor entities, pharmaceutical partnersor other sources of pharmaceuticals or medical equipment, and/or supportpersonnel or other personnel running the system 516, depending upon theembodiment of use.

In another example embodiment, where the DDMS 516 is located on onecomputing device 500, the user interface layer 532 provides a number ofmenus to the user to navigate through the DDMS. These menus may becreated utilizing any menu format, including but not limited to HTML,XML, or Active Server pages. A user may access the DDMS 516 to performone or more of a variety of tasks, such as accessing general informationmade available on a website to all subjects or groups of subjects. Theuser interface layer 532 of the DDMS 516 may allow a user to accessspecific information or to generate reports regarding that subject'smedical condition or that subject's medical device(s) 512, to transferdata or other information from that subject's support device(s) 512 tothe system 516, to transfer data, programs, program updates or otherinformation from the system 516 to the subject's support device(s) 512,to manually enter information into the system 516, to engage in a remoteconsultation exchange with a healthcare provider, or to modify thecustom settings in a subject's supported device and/or in a subject'sDDMS/MDMS data file.

The system 516 may provide access to different optional resources oractivities (including accessing different information items andservices) to different users and to different types or groups of users,such that each user may have a customized experience and/or each type orgroup of users (e.g., all users, diabetic users, cardio users,healthcare provider-user or payor-user, or the like) may have adifferent set of information items or services available on the system.The system 516 may include or employ one or more suitable resourceprovisioning program or system for allocating appropriate resources toeach user or type of user, based on a pre-defined authorization plan.Resource provisioning systems are well known in connection withprovisioning of electronic office resources (email, software programsunder license, sensitive data, etc.) in an office environment, forexample, in a local area network LAN for an office, company or firm. Inone example embodiment, such resource provisioning systems is adapted tocontrol access to medical information and services on the DDMS 516,based on the type of user and/or the identity of the user.

Upon entering successful verification of the user's identificationinformation and password, the user may be provided access to secure,personalized information stored on the DDMS 516. For example, the usermay be provided access to a secure, personalized location in the DDMS516 which has been assigned to the subject. This personalized locationmay be referred to as a personalized screen, a home screen, a home menu,a personalized page, etc. The personalized location may provide apersonalized home screen to the subject, including selectable icons ormenu items for selecting optional activities, including, for example, anoption to transfer device data from a subject's supported device 512 tothe system 516, manually enter additional data into the system 516,modify the subject's custom settings, and/or view and print reports.Reports may include data specific to the subject's condition, includingbut not limited to, data obtained from the subject's support device(s)512, data manually entered, data from medical libraries or othernetworked therapy management systems, data from the subjects or groupsof subjects, or the like. Where the reports include subject-specificinformation and subject identification information, the reports may begenerated from some or all subject data stored in a secure storage area(e.g., storage devices 529) employed by the database layer 528.

The user may select an option to transfer (send) device data to themedical data management system 516. If the system 516 receives a user'srequest to transfer device data to the system, the system 516 mayprovide the user with step-by-step instructions on how to transfer datafrom the subject's supported device(s) 512. For example, the DDMS 516may have a plurality of different stored instruction sets forinstructing users how to download data from different types of subjectsupport devices, where each instruction set relates to a particular typeof subject supported device (e.g., pump, sensor, meter, or the like), aparticular manufacturer's version of a type of subject support device,or the like. Registration information received from the user duringregistration may include information regarding the type of subjectsupport device(s) 512 used by the subject. The system 516 employs thatinformation to select the stored instruction set(s) associated with theparticular subject's support device(s) 512 for display to the user.

Other activities or resources available to the user on the system 516may include an option for manually entering information to the DDMS/MDMS516. For example, from the user's personalized menu or location, theuser may select an option to manually enter additional information intothe system 516.

Further optional activities or resources may be available to the user onthe DDMS 516. For example, from the user's personalized menu, the usermay select an option to receive data, software, software updates,treatment recommendations or other information from the system 516 onthe subject's support device(s) 512. If the system 516 receives arequest from a user to receive data, software, software updates,treatment recommendations or other information, the system 516 mayprovide the user with a list or other arrangement of multiple selectableicons or other indicia representing available data, software, softwareupdates or other information available to the user.

Yet further optional activities or resources may be available to theuser on the medical data management system 516 including, for example,an option for the user to customize or otherwise further personalize theuser's personalized location or menu. In particular, from the user'spersonalized location, the user may select an option to customizeparameters for the user. In addition, the user may create profiles ofcustomizable parameters. When the system 516 receives such a requestfrom a user, the system 516 may provide the user with a list or otherarrangement of multiple selectable icons or other indicia representingparameters that may be modified to accommodate the user's preferences.When a user selects one or more of the icons or other indicia, thesystem 516 may receive the user's request and makes the requestedmodification.

Infusion System Overview

FIG. 6 depicts one exemplary embodiment of an infusion system 600 thatincludes, without limitation, a fluid infusion device (or infusion pump)602, a sensing arrangement 604, a command control device (CCD) 606, anda computer 608, which could be realized as any one of the computingdevices 206, 210, 500, 512 described above. The components of aninfusion system 600 may be realized using different platforms, designs,and configurations, and the embodiment shown in FIG. 6 is not exhaustiveor limiting. In practice, the infusion device 602 and the sensingarrangement 604 are secured at desired locations on the body of a user(or patient), as illustrated in FIG. 6 . In this regard, the locationsat which the infusion device 602 and the sensing arrangement 604 aresecured to the body of the user in FIG. 6 are provided only as arepresentative, non-limiting, example. The elements of the infusionsystem 600 may be similar to those described in U.S. Pat. No. 8,674,288,the subject matter of which is hereby incorporated by reference in itsentirety.

In the illustrated embodiment of FIG. 6 , the infusion device 602 isdesigned as a portable medical device suitable for infusing a fluid, aliquid, a gel, or other agent into the body of a user. In exemplaryembodiments, the infused fluid is insulin, although many other fluidsmay be administered through infusion such as, but not limited to, HIVdrugs, drugs to treat pulmonary hypertension, iron chelation drugs, painmedications, anti-cancer treatments, medications, vitamins, hormones, orthe like. In some embodiments, the fluid may include a nutritionalsupplement, a dye, a tracing medium, a saline medium, a hydrationmedium, or the like.

The sensing arrangement 604 generally represents the components of theinfusion system 600 configured to sense, detect, measure or otherwisequantify a condition of the user, and may include a sensor, a monitor,or the like, for providing data indicative of the condition that issensed, detected, measured or otherwise monitored by the sensingarrangement. In this regard, the sensing arrangement 604 may includeelectronics and enzymes reactive to a biological or physiologicalcondition of the user, such as a blood glucose level, or the like, andprovide data indicative of the blood glucose level to the infusiondevice 602, the CCD 606 and/or the computer 608. For example, theinfusion device 602, the CCD 606 and/or the computer 608 may include adisplay for presenting information or data to the user based on thesensor data received from the sensing arrangement 604, such as, forexample, a current glucose level of the user, a graph or chart of theuser's glucose level versus time, device status indicators, alertmessages, or the like. In other embodiments, the infusion device 602,the CCD 606 and/or the computer 608 may include electronics and softwarethat are configured to analyze sensor data and operate the infusiondevice 602 to deliver fluid to the body of the user based on the sensordata and/or preprogrammed delivery routines. Thus, in exemplaryembodiments, one or more of the infusion device 602, the sensingarrangement 604, the CCD 606, and/or the computer 608 includes atransmitter, a receiver, and/or other transceiver electronics that allowfor communication with other components of the infusion system 600, sothat the sensing arrangement 604 may transmit sensor data or monitordata to one or more of the infusion device 602, the CCD 606 and/or thecomputer 608.

Still referring to FIG. 6 , in various embodiments, the sensingarrangement 604 may be secured to the body of the user or embedded inthe body of the user at a location that is remote from the location atwhich the infusion device 602 is secured to the body of the user. Invarious other embodiments, the sensing arrangement 604 may beincorporated within the infusion device 602. In other embodiments, thesensing arrangement 604 may be separate and apart from the infusiondevice 602, and may be, for example, part of the CCD 606. In suchembodiments, the sensing arrangement 604 may be configured to receive abiological sample, analyte, or the like, to measure a condition of theuser.

In various embodiments, the CCD 606 and/or the computer 608 may includeelectronics and other components configured to perform processing,delivery routine storage, and to control the infusion device 602 in amanner that is influenced by sensor data measured by and/or receivedfrom the sensing arrangement 604. By including control functions in theCCD 606 and/or the computer 608, the infusion device 602 may be madewith more simplified electronics. However, in other embodiments, theinfusion device 602 may include all control functions, and may operatewithout the CCD 606 and/or the computer 608. In various embodiments, theCCD 606 may be a portable electronic device. In addition, in variousembodiments, the infusion device 602 and/or the sensing arrangement 604may be configured to transmit data to the CCD 606 and/or the computer608 for display or processing of the data by the CCD 606 and/or thecomputer 608.

In some embodiments, the CCD 606 and/or the computer 608 may provideinformation to the user that facilitates the user's subsequent use ofthe infusion device 602. For example, the CCD 606 may provideinformation to the user to allow the user to determine the rate or doseof medication to be administered into the user's body. In otherembodiments, the CCD 606 may provide information to the infusion device602 to autonomously control the rate or dose of medication administeredinto the body of the user. In some embodiments, the sensing arrangement604 may be integrated into the CCD 606. Such embodiments may allow theuser to monitor a condition by providing, for example, a sample of hisor her blood to the sensing arrangement 604 to assess his or hercondition. In some embodiments, the sensing arrangement 604 and the CCD606 may be used for determining glucose levels in the blood and/or bodyfluids of the user without the use of, or necessity of, a wire or cableconnection between the infusion device 602 and the sensing arrangement604 and/or the CCD 606.

In one or more exemplary embodiments, the sensing arrangement 604 and/orthe infusion device 602 are cooperatively configured to utilize aclosed-loop system for delivering fluid to the user. Examples of sensingdevices and/or infusion pumps utilizing closed-loop systems may be foundat, but are not limited to, the following U.S. Pat. Nos. 6,088,608,6,119,028, 6,589,229, 6,740,072, 6,827,702, 7,323,142, and 7,402,153,all of which are incorporated herein by reference in their entirety. Insuch embodiments, the sensing arrangement 604 is configured to sense ormeasure a condition of the user, such as, blood glucose level or thelike. The infusion device 602 is configured to deliver fluid in responseto the condition sensed by the sensing arrangement 604. In turn, thesensing arrangement 604 continues to sense or otherwise quantify acurrent condition of the user, thereby allowing the infusion device 602to deliver fluid continuously in response to the condition currently (ormost recently) sensed by the sensing arrangement 604 indefinitely. Insome embodiments, the sensing arrangement 604 and/or the infusion device602 may be configured to utilize the closed-loop system only for aportion of the day, for example only when the user is asleep or awake.

FIGS. 7-9 depict one exemplary embodiment of a fluid infusion device 700(or alternatively, infusion pump) suitable for use in an infusionsystem, such as, for example, as infusion device 602 in the infusionsystem 600 of FIG. 6 . The fluid infusion device 700 is a portablemedical device designed to be carried or worn by a patient (or user),and the fluid infusion device 700 may leverage any number ofconventional features, components, elements, and characteristics ofexisting fluid infusion devices, such as, for example, some of thefeatures, components, elements, and/or characteristics described in U.S.Pat. Nos. 6,485,465 and 7,621,893. It should be appreciated that FIGS.7-9 depict some aspects of the infusion device 700 in a simplifiedmanner; in practice, the infusion device 700 could include additionalelements, features, or components that are not shown or described indetail herein.

As best illustrated in FIGS. 7-8 , the illustrated embodiment of thefluid infusion device 700 includes a housing 702 adapted to receive afluid-containing reservoir 705. An opening 720 in the housing 702accommodates a fitting 723 (or cap) for the reservoir 705, with thefitting 723 being configured to mate or otherwise interface with tubing721 of an infusion set 725 that provides a fluid path to/from the bodyof the user. In this manner, fluid communication from the interior ofthe reservoir 705 to the user is established via the tubing 721. Theillustrated fluid infusion device 700 includes a human-machine interface(HMI) 730 (or user interface) that includes elements 732, 734 that canbe manipulated by the user to administer a bolus of fluid (e.g.,insulin), to change therapy settings, to change user preferences, toselect display features, and the like. The infusion device also includesa display element 726, such as a liquid crystal display (LCD) or anothersuitable display element, that can be used to present various types ofinformation or data to the user, such as, without limitation: thecurrent glucose level of the patient; the time; a graph or chart of thepatient's glucose level versus time; device status indicators; etc.

The housing 702 is formed from a substantially rigid material having ahollow interior 714 adapted to allow an electronics assembly 704, asliding member (or slide) 706, a drive system 708, a sensor assembly710, and a drive system capping member 712 to be disposed therein inaddition to the reservoir 705, with the contents of the housing 702being enclosed by a housing capping member 716. The opening 720, theslide 706, and the drive system 708 are coaxially aligned in an axialdirection (indicated by arrow 718), whereby the drive system 708facilitates linear displacement of the slide 706 in the axial direction718 to dispense fluid from the reservoir 705 (after the reservoir 705has been inserted into opening 720), with the sensor assembly 710 beingconfigured to measure axial forces (e.g., forces aligned with the axialdirection 718) exerted on the sensor assembly 710 responsive tooperating the drive system 708 to displace the slide 706. In variousembodiments, the sensor assembly 710 may be utilized to detect one ormore of the following: an occlusion in a fluid path that slows,prevents, or otherwise degrades fluid delivery from the reservoir 705 toa user's body; when the reservoir 705 is empty; when the slide 706 isproperly seated with the reservoir 705; when a fluid dose has beendelivered; when the infusion pump 700 is subjected to shock orvibration; when the infusion pump 700 requires maintenance.

Depending on the embodiment, the fluid-containing reservoir 705 may berealized as a syringe, a vial, a cartridge, a bag, or the like. Incertain embodiments, the infused fluid is insulin, although many otherfluids may be administered through infusion such as, but not limited to,HIV drugs, drugs to treat pulmonary hypertension, iron chelation drugs,pain medications, anti-cancer treatments, medications, vitamins,hormones, or the like. As best illustrated in FIGS. 8-9 , the reservoir705 typically includes a reservoir barrel 719 that contains the fluidand is concentrically and/or coaxially aligned with the slide 706 (e.g.,in the axial direction 718) when the reservoir 705 is inserted into theinfusion pump 700. The end of the reservoir 705 proximate the opening720 may include or otherwise mate with the fitting 723, which securesthe reservoir 705 in the housing 702 and prevents displacement of thereservoir 705 in the axial direction 718 with respect to the housing 702after the reservoir 705 is inserted into the housing 702. As describedabove, the fitting 723 extends from (or through) the opening 720 of thehousing 702 and mates with tubing 721 to establish fluid communicationfrom the interior of the reservoir 705 (e.g., reservoir barrel 719) tothe user via the tubing 721 and infusion set 725. The opposing end ofthe reservoir 705 proximate the slide 706 includes a plunger 717 (orstopper) positioned to push fluid from inside the barrel 719 of thereservoir 705 along a fluid path through tubing 721 to a user. The slide706 is configured to mechanically couple or otherwise engage with theplunger 717, thereby becoming seated with the plunger 717 and/orreservoir 705. Fluid is forced from the reservoir 705 via tubing 721 asthe drive system 708 is operated to displace the slide 706 in the axialdirection 718 toward the opening 720 in the housing 702.

In the illustrated embodiment of FIGS. 8-9 , the drive system 708includes a motor assembly 707 and a drive screw 709. The motor assembly707 includes a motor that is coupled to drive train components of thedrive system 708 that are configured to convert rotational motor motionto a translational displacement of the slide 706 in the axial direction718, and thereby engaging and displacing the plunger 717 of thereservoir 705 in the axial direction 718. In some embodiments, the motorassembly 707 may also be powered to translate the slide 706 in theopposing direction (e.g., the direction opposite direction 718) toretract and/or detach from the reservoir 705 to allow the reservoir 705to be replaced. In exemplary embodiments, the motor assembly 707includes a brushless DC (BLDC) motor having one or more permanentmagnets mounted, affixed, or otherwise disposed on its rotor. However,the subject matter described herein is not necessarily limited to usewith BLDC motors, and in alternative embodiments, the motor may berealized as a solenoid motor, an AC motor, a stepper motor, apiezoelectric caterpillar drive, a shape memory actuator drive, anelectrochemical gas cell, a thermally driven gas cell, a bimetallicactuator, or the like. The drive train components may comprise one ormore lead screws, cams, ratchets, jacks, pulleys, pawls, clamps, gears,nuts, slides, bearings, levers, beams, stoppers, plungers, sliders,brackets, guides, bearings, supports, bellows, caps, diaphragms, bags,heaters, or the like. In this regard, although the illustratedembodiment of the infusion pump utilizes a coaxially aligned drivetrain, the motor could be arranged in an offset or otherwise non-coaxialmanner, relative to the longitudinal axis of the reservoir 705.

As best shown in FIG. 9 , the drive screw 709 mates with threads 902internal to the slide 706. When the motor assembly 707 is powered andoperated, the drive screw 709 rotates, and the slide 706 is forced totranslate in the axial direction 718. In an exemplary embodiment, theinfusion pump 700 includes a sleeve 711 to prevent the slide 706 fromrotating when the drive screw 709 of the drive system 708 rotates. Thus,rotation of the drive screw 709 causes the slide 706 to extend orretract relative to the drive motor assembly 707. When the fluidinfusion device is assembled and operational, the slide 706 contacts theplunger 717 to engage the reservoir 705 and control delivery of fluidfrom the infusion pump 700. In an exemplary embodiment, the shoulderportion 715 of the slide 706 contacts or otherwise engages the plunger717 to displace the plunger 717 in the axial direction 718. Inalternative embodiments, the slide 706 may include a threaded tip 713capable of being detachably engaged with internal threads 904 on theplunger 717 of the reservoir 705, as described in detail in U.S. Pat.Nos. 6,248,093 and 6,485,465, which are incorporated by referenceherein.

As illustrated in FIG. 8 , the electronics assembly 704 includes controlelectronics 724 coupled to the display element 726, with the housing 702including a transparent window portion 728 that is aligned with thedisplay element 726 to allow the display 726 to be viewed by the userwhen the electronics assembly 704 is disposed within the interior 714 ofthe housing 702. The control electronics 724 generally represent thehardware, firmware, processing logic and/or software (or combinationsthereof) configured to control operation of the motor assembly 707and/or drive system 708, as described in greater detail below in thecontext of FIG. 10 . Whether such functionality is implemented ashardware, firmware, a state machine, or software depends upon theparticular application and design constraints imposed on the embodiment.Those familiar with the concepts described here may implement suchfunctionality in a suitable manner for each particular application, butsuch implementation decisions should not be interpreted as beingrestrictive or limiting. In an exemplary embodiment, the controlelectronics 724 includes one or more programmable controllers that maybe programmed to control operation of the infusion pump 700.

The motor assembly 707 includes one or more electrical leads 736 adaptedto be electrically coupled to the electronics assembly 704 to establishcommunication between the control electronics 724 and the motor assembly707. In response to command signals from the control electronics 724that operate a motor driver (e.g., a power converter) to regulate theamount of power supplied to the motor from a power supply, the motoractuates the drive train components of the drive system 708 to displacethe slide 706 in the axial direction 718 to force fluid from thereservoir 705 along a fluid path (including tubing 721 and an infusionset), thereby administering doses of the fluid contained in thereservoir 705 into the user's body. Preferably, the power supply isrealized one or more batteries contained within the housing 702.Alternatively, the power supply may be a solar panel, capacitor, AC orDC power supplied through a power cord, or the like. In someembodiments, the control electronics 724 may operate the motor of themotor assembly 707 and/or drive system 708 in a stepwise manner,typically on an intermittent basis; to administer discrete precise dosesof the fluid to the user according to programmed delivery profiles.

Referring to FIGS. 7-9 , as described above, the user interface 730includes HMI elements, such as buttons 732 and a directional pad 734,that are formed on a graphic keypad overlay 731 that overlies a keypadassembly 733, which includes features corresponding to the buttons 732,directional pad 734 or other user interface items indicated by thegraphic keypad overlay 731. When assembled, the keypad assembly 733 iscoupled to the control electronics 724, thereby allowing the HMIelements 732, 734 to be manipulated by the user to interact with thecontrol electronics 724 and control operation of the infusion pump 700,for example, to administer a bolus of insulin, to change therapysettings, to change user preferences, to select display features, to setor disable alarms and reminders, and the like. In this regard, thecontrol electronics 724 maintains and/or provides information to thedisplay 726 regarding program parameters, delivery profiles, pumpoperation, alarms, warnings, statuses, or the like, which may beadjusted using the HMI elements 732, 734. In various embodiments, theHMI elements 732, 734 may be realized as physical objects (e.g.,buttons, knobs, joysticks, and the like) or virtual objects (e.g., usingtouch-sensing and/or proximity-sensing technologies). For example, insome embodiments, the display 726 may be realized as a touch screen ortouch-sensitive display, and in such embodiments, the features and/orfunctionality of the HMI elements 732, 734 may be integrated into thedisplay 726 and the HMI 730 may not be present. In some embodiments, theelectronics assembly 704 may also include alert generating elementscoupled to the control electronics 724 and suitably configured togenerate one or more types of feedback, such as, without limitation:audible feedback; visual feedback; haptic (physical) feedback; or thelike.

Referring to FIGS. 8-9 , in accordance with one or more embodiments, thesensor assembly 710 includes a back plate structure 750 and a loadingelement 760. The loading element 760 is disposed between the cappingmember 712 and a beam structure 770 that includes one or more beamshaving sensing elements disposed thereon that are influenced bycompressive force applied to the sensor assembly 710 that deflects theone or more beams, as described in greater detail in U.S. Pat. No.8,474,332, which is incorporated by reference herein. In exemplaryembodiments, the back plate structure 750 is affixed, adhered, mounted,or otherwise mechanically coupled to the bottom surface 738 of the drivesystem 708 such that the back plate structure 750 resides between thebottom surface 738 of the drive system 708 and the housing cap 716. Thedrive system capping member 712 is contoured to accommodate and conformto the bottom of the sensor assembly 710 and the drive system 708. Thedrive system capping member 712 may be affixed to the interior of thehousing 702 to prevent displacement of the sensor assembly 710 in thedirection opposite the direction of force provided by the drive system708 (e.g., the direction opposite direction 718). Thus, the sensorassembly 710 is positioned between the motor assembly 707 and secured bythe capping member 712, which prevents displacement of the sensorassembly 710 in a downward direction opposite the direction of arrow718, such that the sensor assembly 710 is subjected to a reactionarycompressive force when the drive system 708 and/or motor assembly 707 isoperated to displace the slide 706 in the axial direction 718 inopposition to the fluid pressure in the reservoir 705. Under normaloperating conditions, the compressive force applied to the sensorassembly 710 is correlated with the fluid pressure in the reservoir 705.As shown, electrical leads 740 are adapted to electrically couple thesensing elements of the sensor assembly 710 to the electronics assembly704 to establish communication to the control electronics 724, whereinthe control electronics 724 are configured to measure, receive, orotherwise obtain electrical signals from the sensing elements of thesensor assembly 710 that are indicative of the force applied by thedrive system 708 in the axial direction 718.

FIG. 10 depicts an exemplary embodiment of a control system 1000suitable for use with an infusion device 1002, such as any one of theinfusion devices 202, 602, 700 described above. The control system 1000is capable of controlling or otherwise regulating a physiologicalcondition in the body 1001 of a user to a desired (or target) value orotherwise maintain the condition within a range of acceptable values inan automated or autonomous manner. In one or more exemplary embodiments,the condition being regulated is sensed, detected, measured or otherwisequantified by a sensing arrangement 1004 (e.g., sensing arrangement 604)communicatively coupled to the infusion device 1002. However, it shouldbe noted that in alternative embodiments, the condition being regulatedby the control system 1000 may be correlative to the measured valuesobtained by the sensing arrangement 1004. That said, for clarity andpurposes of explanation, the subject matter may be described herein inthe context of the sensing arrangement 1004 being realized as a glucosesensing arrangement that senses, detects, measures or otherwisequantifies the user's glucose level, which is being regulated in thebody 1001 of the user by the control system 1000.

In exemplary embodiments, the sensing arrangement 1004 includes one ormore interstitial glucose sensing elements that generate or otherwiseoutput electrical signals having a signal characteristic that iscorrelative to, influenced by, or otherwise indicative of the relativeinterstitial fluid glucose level in the body 1001 of the user. Theoutput electrical signals are filtered or otherwise processed to obtaina measurement value indicative of the user's interstitial fluid glucoselevel. In exemplary embodiments, a blood glucose meter 1030, such as afinger stick device, is utilized to directly sense, detect, measure orotherwise quantify the blood glucose in the body 1001 of the user. Inthis regard, the blood glucose meter 1030 outputs or otherwise providesa measured blood glucose value that may be utilized as a referencemeasurement for calibrating the sensing arrangement 1004 and convertinga measurement value indicative of the user's interstitial fluid glucoselevel into a corresponding calibrated blood glucose value. For purposesof explanation, the calibrated blood glucose value calculated based onthe electrical signals output by the sensing element(s) of the sensingarrangement 1004 may alternatively be referred to herein as the sensorglucose value, the sensed glucose value, or variants thereof.

In the illustrated embodiment, the pump control system 1020 generallyrepresents the electronics and other components of the infusion device1002 that control operation of the fluid infusion device 1002 accordingto a desired infusion delivery program in a manner that is influenced bythe sensed glucose value indicative of a current glucose level in thebody 1001 of the user. For example, to support a closed-loop operatingmode, the pump control system 1020 maintains, receives, or otherwiseobtains a target or commanded glucose value, and automatically generatesor otherwise determines dosage commands for operating an actuationarrangement, such as a motor 1007, to displace the plunger 1017 anddeliver insulin to the body 1001 of the user based on the differencebetween a sensed glucose value and the target glucose value. In otheroperating modes, the pump control system 1020 may generate or otherwisedetermine dosage commands configured to maintain the sensed glucosevalue below an upper glucose limit, above a lower glucose limit, orotherwise within a desired range of glucose values. In practice, theinfusion device 1002 may store or otherwise maintain the target value,upper and/or lower glucose limit(s), and/or other glucose thresholdvalue(s) in a data storage element accessible to the pump control system1020.

The target glucose value and other threshold glucose values may bereceived from an external component (e.g., CCD 606 and/or computingdevice 608) or be input by a user via a user interface element 1040associated with the infusion device 1002. In practice, the one or moreuser interface element(s) 1040 associated with the infusion device 1002typically include at least one input user interface element, such as,for example, a button, a keypad, a keyboard, a knob, a joystick, amouse, a touch panel, a touchscreen, a microphone or another audio inputdevice, and/or the like. Additionally, the one or more user interfaceelement(s) 1040 include at least one output user interface element, suchas, for example, a display element (e.g., a light-emitting diode or thelike), a display device (e.g., a liquid crystal display or the like), aspeaker or another audio output device, a haptic feedback device, or thelike, for providing notifications or other information to the user. Itshould be noted that although FIG. 10 depicts the user interfaceelement(s) 1040 as being separate from the infusion device 1002, inpractice, one or more of the user interface element(s) 1040 may beintegrated with the infusion device 1002. Furthermore, in someembodiments, one or more user interface element(s) 1040 are integratedwith the sensing arrangement 1004 in addition to and/or in alternativeto the user interface element(s) 1040 integrated with the infusiondevice 1002. The user interface element(s) 1040 may be manipulated bythe user to operate the infusion device 1002 to deliver correctionboluses, adjust target and/or threshold values, modify the deliverycontrol scheme or operating mode, and the like, as desired.

Still referring to FIG. 10 , in the illustrated embodiment, the infusiondevice 1002 includes a motor control module 1012 coupled to a motor 1007(e.g., motor assembly 707) that is operable to displace a plunger 1017(e.g., plunger 717) in a reservoir (e.g., reservoir 705) and provide adesired amount of fluid to the body 1001 of a user. In this regard,displacement of the plunger 1017 results in the delivery of a fluid thatis capable of influencing the condition in the body 1001 of the user tothe body 1001 of the user via a fluid delivery path (e.g., via tubing721 of an infusion set 725). A motor driver module 1014 is coupledbetween an energy source 1003 and the motor 1007. The motor controlmodule 1012 is coupled to the motor driver module 1014, and the motorcontrol module 1012 generates or otherwise provides command signals thatoperate the motor driver module 1014 to provide current (or power) fromthe energy source 1003 to the motor 1007 to displace the plunger 1017 inresponse to receiving, from a pump control system 1020, a dosage commandindicative of the desired amount of fluid to be delivered.

In exemplary embodiments, the energy source 1003 is realized as abattery housed within the infusion device 1002 (e.g., within housing702) that provides direct current (DC) power. In this regard, the motordriver module 1014 generally represents the combination of circuitry,hardware and/or other electrical components configured to convert orotherwise transfer DC power provided by the energy source 1003 intoalternating electrical signals applied to respective phases of thestator windings of the motor 1007 that result in current flowing throughthe stator windings that generates a stator magnetic field and causesthe rotor of the motor 1007 to rotate. The motor control module 1012 isconfigured to receive or otherwise obtain a commanded dosage from thepump control system 1020, convert the commanded dosage to a commandedtranslational displacement of the plunger 1017, and command, signal, orotherwise operate the motor driver module 1014 to cause the rotor of themotor 1007 to rotate by an amount that produces the commandedtranslational displacement of the plunger 1017. For example, the motorcontrol module 1012 may determine an amount of rotation of the rotorrequired to produce translational displacement of the plunger 1017 thatachieves the commanded dosage received from the pump control system1020. Based on the current rotational position (or orientation) of therotor with respect to the stator that is indicated by the output of therotor sensing arrangement 1016, the motor control module 1012 determinesthe appropriate sequence of alternating electrical signals to be appliedto the respective phases of the stator windings that should rotate therotor by the determined amount of rotation from its current position (ororientation). In embodiments where the motor 1007 is realized as a BLDCmotor, the alternating electrical signals commutate the respectivephases of the stator windings at the appropriate orientation of therotor magnetic poles with respect to the stator and in the appropriateorder to provide a rotating stator magnetic field that rotates the rotorin the desired direction. Thereafter, the motor control module 1012operates the motor driver module 1014 to apply the determinedalternating electrical signals (e.g., the command signals) to the statorwindings of the motor 1007 to achieve the desired delivery of fluid tothe user.

When the motor control module 1012 is operating the motor driver module1014, current flows from the energy source 1003 through the statorwindings of the motor 1007 to produce a stator magnetic field thatinteracts with the rotor magnetic field. In some embodiments, after themotor control module 1012 operates the motor driver module 1014 and/ormotor 1007 to achieve the commanded dosage, the motor control module1012 ceases operating the motor driver module 1014 and/or motor 1007until a subsequent dosage command is received. In this regard, the motordriver module 1014 and the motor 1007 enter an idle state during whichthe motor driver module 1014 effectively disconnects or isolates thestator windings of the motor 1007 from the energy source 1003. In otherwords, current does not flow from the energy source 1003 through thestator windings of the motor 1007 when the motor 1007 is idle, and thus,the motor 1007 does not consume power from the energy source 1003 in theidle state, thereby improving efficiency.

Depending on the embodiment, the motor control module 1012 may beimplemented or realized with a general-purpose processor, amicroprocessor, a controller, a microcontroller, a state machine, acontent addressable memory, an application specific integrated circuit,a field programmable gate array, any suitable programmable logic device,discrete gate or transistor logic, discrete hardware components, or anycombination thereof, designed to perform the functions described herein.In exemplary embodiments, the motor control module 1012 includes orotherwise accesses a data storage element or memory, including any sortof random access memory (RAM), read only memory (ROM), flash memory,registers, hard disks, removable disks, magnetic or optical massstorage, or any other short or long-term storage media or othernon-transitory computer-readable medium, which is capable of storingprogramming instructions for execution by the motor control module 1012.The computer-executable programming instructions, when read and executedby the motor control module 1012, cause the motor control module 1012 toperform or otherwise support the tasks, operations, functions, andprocesses described herein.

It should be appreciated that FIG. 10 is a simplified representation ofthe infusion device 1002 for purposes of explanation and is not intendedto limit the subject matter described herein in any way. In this regard,depending on the embodiment, some features and/or functionality of thesensing arrangement 1004 may be implemented by or otherwise integratedinto the pump control system 1020, or vice versa. Similarly, inpractice, the features and/or functionality of the motor control module1012 may be implemented by or otherwise integrated into the pump controlsystem 1020, or vice versa. Furthermore, the features and/orfunctionality of the pump control system 1020 may be implemented bycontrol electronics 724 located in the fluid infusion device 700, whilein alternative embodiments, the pump control system 1020 may beimplemented by a remote computing device that is physically distinctand/or separate from the infusion device 1002, such as, for example, theCCD 606 or the computing device 608.

FIG. 11 depicts an exemplary embodiment of a pump control system 1100suitable for use as the pump control system 1020 in FIG. 10 inaccordance with one or more embodiments. The illustrated pump controlsystem 1100 includes, without limitation, a pump control module 1102, acommunications interface 1104, and a data storage element (or memory)1106. The pump control module 1102 is coupled to the communicationsinterface 1104 and the memory 1106, and the pump control module 1102 issuitably configured to support the operations, tasks, and/or processesdescribed herein. In exemplary embodiments, the pump control module 1102is also coupled to one or more user interface elements 1108 (e.g., userinterface 730, 1040) for receiving user input and providingnotifications, alerts, or other therapy information to the user.Although FIG. 11 depicts the user interface element 1108 as beingseparate from the pump control system 1100, in various alternativeembodiments, the user interface element 1108 may be integrated with thepump control system 1100 (e.g., as part of the infusion device 700,1002), the sensing arrangement 1004 or another element of an infusionsystem 600 (e.g., the computer 608 or CCD 606).

Referring to FIG. 11 and with reference to FIG. 10 , the communicationsinterface 1104 generally represents the hardware, circuitry, logic,firmware and/or other components of the pump control system 1100 thatare coupled to the pump control module 1102 and configured to supportcommunications between the pump control system 1100 and the sensingarrangement 1004. In this regard, the communications interface 1104 mayinclude or otherwise be coupled to one or more transceiver modulescapable of supporting wireless communications between the pump controlsystem 1020, 1100 and the sensing arrangement 1004 or another electronicdevice 206, 210, 500, 512, 606, 608 in an infusion system 600 or amanagement system 200, 516. For example, the communications interface1104 may be utilized to receive sensor measurement values or othermeasurement data from a sensing arrangement 604, 1004 as well as uploadsuch sensor measurement values to a server 206 or other computing device210, 500, 512, 1008 for purposes of generating a report including asnapshot GUI display as described above in the context of FIGS. 1-6 . Inother embodiments, the communications interface 1104 may be configuredto support wired communications to/from the sensing arrangement 1004.

The pump control module 1102 generally represents the hardware,circuitry, logic, firmware and/or other component of the pump controlsystem 1100 that is coupled to the communications interface 1104 andconfigured to determine dosage commands for operating the motor 1007 todeliver fluid to the body 1001 based on data received from the sensingarrangement 1004 and perform various additional tasks, operations,functions and/or operations described herein. For example, in exemplaryembodiments, pump control module 1102 implements or otherwise executes acommand generation application 1110 that supports one or more autonomousoperating modes and calculates or otherwise determines dosage commandsfor operating the motor 1007 of the infusion device 1002 in anautonomous operating mode based at least in part on a currentmeasurement value for a condition in the body 1001 of the user. Forexample, in a closed-loop operating mode, the command generationapplication 1110 may determine a dosage command for operating the motor1007 to deliver insulin to the body 1001 of the user based at least inpart on the current glucose measurement value most recently receivedfrom the sensing arrangement 1004 to regulate the user's blood glucoselevel to a target reference glucose value. Additionally, the commandgeneration application 610 may generate dosage commands for boluses thatare manually-initiated or otherwise instructed by a user via a userinterface element 1108.

Still referring to FIG. 11 , depending on the embodiment, the pumpcontrol module 1102 may be implemented or realized with a generalpurpose processor, a microprocessor, a controller, a microcontroller, astate machine, a content addressable memory, an application specificintegrated circuit, a field programmable gate array, any suitableprogrammable logic device, discrete gate or transistor logic, discretehardware components, or any combination thereof, designed to perform thefunctions described herein. In this regard, the steps of a method oralgorithm described in connection with the embodiments disclosed hereinmay be embodied directly in hardware, in firmware, in a software moduleexecuted by the pump control module 1102, or in any practicalcombination thereof. In exemplary embodiments, the pump control module1102 includes or otherwise accesses the data storage element or memory1106, which may be realized using any sort of non-transitorycomputer-readable medium capable of storing programming instructions forexecution by the pump control module 1102. The computer-executableprogramming instructions, when read and executed by the pump controlmodule 1102, cause the pump control module 1102 to implement orotherwise generate the command generation application 1110 and performthe tasks, operations, functions, and processes described in greaterdetail below.

It should be understood that FIG. 11 is a simplified representation of apump control system 1100 for purposes of explanation and is not intendedto limit the subject matter described herein in any way. For example, insome embodiments, the features and/or functionality of the motor controlmodule 1012 may be implemented by or otherwise integrated into the pumpcontrol system 1100 and/or the pump control module 1102, for example, bythe command generation application 1110 converting the dosage commandinto a corresponding motor command, in which case, the separate motorcontrol module 1012 may be absent from an embodiment of the infusiondevice 1002.

FIG. 12 depicts an exemplary closed-loop control system 1200 that may beimplemented by a pump control system 1020, 1100 to provide a closed-loopoperating mode that autonomously regulates a condition in the body of auser to a reference (or target) value. It should be appreciated thatFIG. 12 is a simplified representation of the control system 1200 forpurposes of explanation and is not intended to limit the subject matterdescribed herein in any way.

In exemplary embodiments, the control system 1200 receives or otherwiseobtains a target glucose value at input 1202. In some embodiments, thetarget glucose value may be stored or otherwise maintained by theinfusion device 1002 (e.g., in memory 1106), however, in somealternative embodiments, the target value may be received from anexternal component (e.g., CCD 606 and/or computer 608). In one or moreembodiments, the target glucose value may be dynamically calculated orotherwise determined prior to entering the closed-loop operating modebased on one or more patient-specific control parameters. For example,the target blood glucose value may be calculated based at least in parton a patient-specific reference basal rate and a patient-specific dailyinsulin requirement, which are determined based on historical deliveryinformation over a preceding interval of time (e.g., the amount ofinsulin delivered over the preceding 24 hours). The control system 1200also receives or otherwise obtains a current glucose measurement value(e.g., the most recently obtained sensor glucose value) from the sensingarrangement 1004 at input 1204. The illustrated control system 1200implements or otherwise provides proportional-integral-derivative (PID)control to determine or otherwise generate delivery commands foroperating the motor 1007 based at least in part on the differencebetween the target glucose value and the current glucose measurementvalue. In this regard, the PID control attempts to minimize thedifference between the measured value and the target value, and therebyregulates the measured value to the desired value. PID controlparameters are applied to the difference between the target glucoselevel at input 1202 and the measured glucose level at input 1204 togenerate or otherwise determine a dosage (or delivery) command providedat output 1230. Based on that delivery command, the motor control module1012 operates the motor 1007 to deliver insulin to the body of the userto influence the user's glucose level, and thereby reduce the differencebetween a subsequently measured glucose level and the target glucoselevel.

The illustrated control system 1200 includes or otherwise implements asummation block 1206 configured to determine a difference between thetarget value obtained at input 1202 and the measured value obtained fromthe sensing arrangement 1004 at input 1204, for example, by subtractingthe target value from the measured value. The output of the summationblock 1206 represents the difference between the measured and targetvalues, which is then provided to each of a proportional term path, anintegral term path, and a derivative term path. The proportional termpath includes a gain block 1220 that multiplies the difference by aproportional gain coefficient, Kp, to obtain the proportional term. Theintegral term path includes an integration block 1208 that integratesthe difference and a gain block 1222 that multiplies the integrateddifference by an integral gain coefficient, to obtain the integral term.The derivative term path includes a derivative block 1210 thatdetermines the derivative of the difference and a gain block 1224 thatmultiplies the derivative of the difference by a derivative gaincoefficient, KD, to obtain the derivative term. The proportional term,the integral term, and the derivative term are then added or otherwisecombined to obtain a delivery command that is utilized to operate themotor at output 1230. Various implementation details pertaining toclosed-loop PID control and determine gain coefficients are described ingreater detail in U.S. Pat. No. 7,402,153, which is incorporated byreference.

In one or more exemplary embodiments, the PID gain coefficients areuser-specific (or patient-specific) and dynamically calculated orotherwise determined prior to entering the closed-loop operating modebased on historical insulin delivery information (e.g., amounts and/ortimings of previous dosages, historical correction bolus information, orthe like), historical sensor measurement values, historical referenceblood glucose measurement values, user-reported or user-input events(e.g., meals, exercise, and the like), and the like. In this regard, oneor more patient-specific control parameters (e.g., an insulinsensitivity factor, a daily insulin requirement, an insulin limit, areference basal rate, a reference fasting glucose, an active insulinaction duration, pharmodynamical time constants, or the like) may beutilized to compensate, correct, or otherwise adjust the PID gaincoefficients to account for various operating conditions experiencedand/or exhibited by the infusion device 1002. The PID gain coefficientsmay be maintained by the memory 1106 accessible to the pump controlmodule 1102. In this regard, the memory 1106 may include a plurality ofregisters associated with the control parameters for the PID control.For example, a first parameter register may store the target glucosevalue and be accessed by or otherwise coupled to the summation block1206 at input 1202, and similarly, a second parameter register accessedby the proportional gain block 1220 may store the proportional gaincoefficient, a third parameter register accessed by the integration gainblock 1222 may store the integration gain coefficient, and a fourthparameter register accessed by the derivative gain block 1224 may storethe derivative gain coefficient.

Therapeutic Recommendations for Event Pattern Mitigation

As described in greater detail below, in exemplary embodiments, at leastone of the detected event patterns presented in a snapshot GUI displayis analyzed to determine one or more recommended remedial actions foraddressing the detected event pattern. In this regard, based on the typeof event pattern detected, the patient's current therapy regimen, andthe patient's physiological condition, recommended modifications oradjustments to the patient's current therapy regimen may be determinedand indicated on the snapshot GUI display. In one or more embodiments,logic rules or formula are maintained and utilized to determine how thepatient's current therapy regimen should be modified given the patient'scurrent therapy configuration, the patient's physiological condition,the event pattern type, and potentially other patient-specific variablesor factors (e.g., the monitoring period associated with the eventpattern, the severity or frequency of events, and the like). Thus, therecommended remedial actions may vary depending on the patient's currenttherapy regimen and dosages, the patient's A1C or glucose levels, thetype of event pattern detected, and so on.

FIG. 13 depicts an exemplary recommendation process 1300 suitable forimplementation by a patient management system in connection with one ormore of the presentation processes 300, 400 described above to providerecommended therapeutic remedial actions for resolving, correcting, orotherwise mitigating an event pattern presented on a GUI display, suchas snapshot GUI display 100 of FIG. 1 . The various tasks performed inconnection with the recommendation process 1300 may be performed byhardware, firmware, software executed by processing circuitry, or anycombination thereof. For illustrative purposes, the followingdescription refers to elements mentioned above in connection with FIG. 2. In practice, portions of the recommendation process 1300 may beperformed by different elements of the patient management system 200,such as, for example, the infusion device 202, the sensing arrangement204, the server 206, the database 208, the client device 210, the clientapplication 212, and/or the processing system 216. It should beappreciated that the recommendation process 1300 may include any numberof additional or alternative tasks, the tasks need not be performed inthe illustrated order and/or the tasks may be performed concurrently,and/or the recommendation process 1300 may be incorporated into a morecomprehensive procedure or process having additional functionality notdescribed in detail herein. Moreover, one or more of the tasks shown anddescribed in the context of FIG. 13 could be omitted from a practicalembodiment of the recommendation process 1300 as long as the intendedoverall functionality remains intact.

The recommendation process 1300 initializes or begins by identifying orotherwise determining the event pattern to be analyzed for recommendingtherapeutic remedial actions (task 1302). In one or more exemplaryembodiments, only the highest priority event pattern from among theprioritized event patterns is identified for analysis. In this regard,remedial actions that may be taken by a patient or user to mitigate orotherwise address the highest priority event pattern could alsoinfluence or resolve the lower priority event patterns, and hence,providing multiple different recommended therapeutic remedial actionsfor multiple different event patterns could be unnecessary andconfusing. However, in alternative embodiments, each of the prioritizedevent patterns displayed on a GUI display (e.g., each of the remainingevent patterns in the filtered prioritized list at 318) may beidentified and analyzed by the recommendation process 1300 to providemultiple different options for therapy modifications that could beundertaken. In yet other embodiments, the recommendation process 1300may be triggered or initiated by user selection of a particular eventpattern for analysis (e.g., from within the event pattern analysisregion or another GUI display), whereby the event pattern whoseselection triggered the recommendation process 1300 is identified as theevent pattern for analysis.

In the illustrated embodiment, the recommendation process 1300 continuesby identifying, obtaining or otherwise determining physiologicalinformation associated with the patient (task 1304). In this regard, theserver 206 obtains or calculates physiological information associatedwith the patient, such as, for example, the estimated A1C (oralternatively, glycohemoglobin or glycated hemoglobin) level calculatedbased on the sensor glucose measurement values over the snapshot timeperiod, the average sensor glucose measurement values over the snapshottime period, the average reference blood glucose measurement values(e.g., from a blood glucose meter) over the snapshot time period, andthe like. Depending on the embodiment, the server 206 may obtain thepatient physiological information from the database 208 and/or infusiondevice 202, or the server 206 may obtain historical sensor measurementsfrom the database 208 and/or infusion device 202 and utilize theobtained historical measurements to calculate the physiologicalinformation associated with the patient for the snapshot time period.

The recommendation process 1300 also identifies, obtains or otherwisedetermines current therapeutic information for the patient (task 1306).In this regard, the recommendation process 1300 identified or determinesthe current medications, dosages, types of therapy, and othertherapeutic settings or configurations associated with the patient. Forexample, the database 208 may maintain a patient profile or similarrecord or entry that maintains an association between one or morepatient identifiers and the current therapy assigned or associated withthe patient, including, the current medications prescribed to thepatient, the type or manner of administration (e.g., basal infusion,boluses or manual injections, oral administration, or the like), thenumber and/or amount of dosages prescribed to the patient, andpotentially other information characterizing the current therapyassociated with the patient. The patient profile in the database 208 mayalso include other clinical or physiological data associated with thepatient that may influence suggested or recommended therapymodifications, such as, for example, the patient's height, weight,cholesterol levels, blood pressure, activity metrics or data, sleepquality data, and the like. In other embodiments, the current therapyinformation may be stored or maintained at one of the infusion device202 and the client device 210 and retrieved by the server 206 via thenetwork 214.

The recommendation process 1300 continues by identifying or otherwiseobtaining therapeutic modification logic associated with the identifiedevent pattern and corresponding to the physiological condition of thepatient and current patient therapy (task 1308). In exemplaryembodiments, the database 208 maintains one or more tables or lists oflogic rules for determining therapy adjustments or modifications inassociation with a particular combination of event pattern, medicationsinvolved in the patient's therapy, and the patient's physiologicalcondition. Thus, different types of adjustments or modifications may beindicated for a particular event pattern, depending on the particularphysiological condition of the patient. For example, an event patterncould potentially be resolved by increasing or decreasing a dosage of aparticular medication rather than adding or removing a medication to thepatient's therapy, depending on the estimated A1C level and/or the meansensor glucose level for the patient. As another example, adjustments ormodifications may be indicated (or not indicated) for a particular eventpattern based on the patient's specific glycemic goals or otherobjectives that may be established by the patient's healthcare provider,or whether or not such goals or objectives have already been achieved.In exemplary embodiments, after identifying the event pattern to beanalyzed for a particular patient and the relevant physiologicalinformation and combination of medications for the patient, the server206 accesses the database 208 (or alternatively another device 202, 210via the network 214) to retrieve the corresponding therapy modificationlogic rules associated with the identified event pattern andcorresponding to the combination of the detected event pattern,combination of medications, and the patient's physiological condition.

Still referring to FIG. 13 , the recommendation process 1300 continuesby determining one or more therapeutic modifications for mitigating,resolving, or otherwise addressing the event pattern by applying theobtained therapy modification logic rules using the patient's currenttherapy configuration and physiological condition (task 1310). Inexemplary embodiments, the server 206 applies the obtained therapymodification logic rules associated with the event pattern to thecurrent dosages associated with the patient's current therapy todetermine recommended therapy modifications for mitigating, resolving,or otherwise addressing the event pattern. For example, if the currentdosage of a particular medication or combination of medications is lessthan a threshold dosage (e.g., one half of the maximum dosage), then thetherapy modification logic rules may identify or otherwise indicate anamount by which a particular medication should be increased. Conversely,when the current dosage of the particular medication or combination ofmedications is greater than the threshold dosage, then the therapymodification logic rules may identify or otherwise indicate anothermedication that should be added to the patient's therapy. For dualtherapy or other therapy configurations with multiple medications, thetherapy modification logic rules may identify or otherwise indicatewhich of the medications should have its dosage adjusted when thecombined dosage is less than a threshold for the combined medications.

In some embodiments, the therapy modification logic rules utilized bythe recommendation process 1300 may also consider patient physiologicalinformation, such as, for example, sensor glucose measurement values orone or more performance metrics calculated based on the historicalmeasurement data for the patient. In this regard, a recommended therapymodification could be influenced by one or more of the estimated A1Clevel calculated based on sensor glucose measurement values over thesnapshot time period or the estimated percentage(s) of the snapshot timeperiod during which the patient's sensor glucose measurement values wereabove an upper glucose threshold value (e.g., 150 mg/dL), below a lowerglucose threshold value (e.g., 70 mg/dL), or between the upper and lowerglucose threshold values corresponding to a target sensor glucose range.Thus, the recommended therapy modification chosen or selected by therecommendation process 1300 may be one that is likely to resolve,mitigate, or otherwise address the identified event pattern, whilesecondarily being most likely to improve one or more performance metricsor other aspects of regulating the patient's physiological condition.

In various embodiments, the recommendation process 1300 may also accountfor other patient-specific variables which may be stored or otherwisemaintained in association with the patient's profile or electronicmedical record in the database 208. For example, the patient's A1C goal,previous therapies, allergies and drug intolerances, informationcharacterizing the patient's renal function, information characterizingthe patient's hepatic function, and the like may be stored in thedatabase 208 and factored in or otherwise accounted for by the therapymodification logic rules. Thus, the recommended therapeutic remedialactions identified by the recommendation process 1300 may be the mostappropriate actions for addressing the identified event pattern,accounting for the patient's physiological condition or glycemic issues,goals or objectives, allergies and drug intolerances, and potentiallyother clinical variables.

Table 1 represents an exemplary set of therapy modification logic rulesthat may be maintained in a database 208. It should be noted that Table1 merely depicts one particular example of therapy modification logicrules for dual combination therapies with a particular A1C level for aparticular event pattern, and in practice, the database 208 may maintainany number of different tables to variously accommodate any number ofpotential event patterns that may be detected, in combination with anynumber of potential therapy configurations and dosages (includingtreatment naïve or naïve therapy, monotherapy, and the like), inassociation with different A1C levels, glucose levels, or other glycemicstatuses. In some embodiments, the therapy modification logic ruletables may be stablished or promulgated by a regulatory agency, however,in alternative embodiments, the therapy modification logic rules may beconfigurable or otherwise specific to a particular doctor, hospital, orother care provider. Accordingly, the subject matter described herein isnot limited to the example therapy modification logic rules of Table 1.

Table 1 depicts therapy modification logic rules associated with ahyperglycemic event pattern associated with a post-meal monitoringperiod for estimated A1C levels below a threshold value of 9%. The logicrules depend on the particular dual combination therapy that the patientit utilizing (e.g., any two of Metformin (Met), a dipeptidyl peptidase 4(DPP-4) inhibitor, a glucagon-like peptide-1 (GLP-1) receptor agonist,Sulfonylurea or glinide (SU/glinide), Thiazolidenedione (TZD), asodium-glucose co-transporter 2 (SGLT-2) inhibitor, or basal insulin),and whether or not the current dosage information is less than one halfof the maximum dosage associated with the particular dual combinationtherapy. For example, for a patient with a current therapy configurationof Metformin and a DPP-4 inhibitor (Met+DPP-4) with a current dosageless than one half the maximum dosage of the dual combination, atherapeutic modification of increasing the dosage of the DPP-4 inhibitormay be identified and recommended or otherwise indicated on a snapshotGUI display for the patient. Alternatively, for a patient with a currenttherapy configuration of Metformin and Thiazolidenedione (Met+TZD) witha current dosage less than one half the maximum dosage of the dualcombination, therapeutic modifications of adding one of a DPP-4inhibitor, a GLP-1 receptor agonist, a SGLT-2 inhibitor, analpha-glucosidase inhibitor (AGI), or pre-meal rapid-acting insulin maybe identified and recommended or otherwise indicated on a snapshot GUIdisplay for the patient, thereby allowing the patient, doctor, nurse, orother clinician to readily identify the need to increase medications andwhich options are likely to be best for the patient given the patient'scurrent therapy configuration.

TABLE 1 Dual Combination Therapy If . . . < 1/2 Max dose of Dual If ≥½Max dose of Dual Combination, Configuration Combination Then Add one ofthe following: Met + DPP-4 Increase dose of DPP-4 if SGLT-2 appropriate;Also, Add one of the AGI drugs on right: Pre-meal rapid-acting insulinMet + GLP-1 Increase dose of GLP-1 if SGLT-2 appropriate; Also, Add oneof the AGI drugs on right: Pre-meal rapid-acting insulin Met +SU/glinide Increase dose of SU/glinide if DPP-4 appropriate; Also, Addone of the GLP-1 drugs on right: SGLT-2 AGI Pre-meal rapid-actinginsulin Met + TZD Add one of the drugs on right: DPP-4 GLP-1 SGLT-2 AGIPre-meal rapid-acting insulin Met + SGLT-2 Increase dose of SGLT-2 ifDPP-4 appropriate; Also, Add one of the GLP-1 drugs on right: AGIPre-meal rapid-acting insulin Met + Basal insulin Add one of the drugson right: DPP-4 GLP-1 SGLT-2 AGI Pre-meal rapid-acting insulinSU/glinide + DPP-4 Increase dose of SU/glinide and/or Met + SGLT-2 DPP-4if appropriate; Also, Add Met + AGI one of the drugs on right: Met +Pre-meal rapid-acting insulin SU/glinide + GLP-1 Increase dose ofSU/glinide and/or Met + SGLT-2 GLP-1 if appropriate; Also, Add Met + AGIone of the drugs on right: Met + Pre-meal rapid-acting insulinSU/glinide + TZD Increase dose of SU/glinide if Met + DPP-4 appropriate;Also, Add one of the Met + GLP-1 drugs on right: Met + SGLT-2 Met + AGIMet + Pre-meal rapid-acting insulin SU/glinide + SGLT-2 Increase dose ofSU/glinide and/or Met + DPP-4 SGLT-2 if appropriate; Also, Add Met +GLP-1 one of the drugs on right: Met + AGI Met + Pre-meal rapid-actinginsulin SU/glinide + Basal Increase dose of SU/glinide, if Met + DPP-4insulin appropriate; Also, Add one of the Met + GLP-1 drugs on right:Met + SGLT-2 Met + AGI Met + Pre-meal rapid-acting insulin TZD + DPP-4Increase dose of TZD and/or DPP- Met + SGLT-2 4, if appropriate Also,Add one of Met + AGI the drugs on right: Met + Pre-meal rapid-actinginsulin TZD + GLP-1 Increase dose of TZD and/or GLP- Met + SGLT-2 1, ifappropriate; Also, Add one of Met + AGI the drugs on right: Met +SU/glinide Met + Pre-meal rapid-acting insulin TZD + SGLT-2 Increasedose of TZD and/or Met + DPP-4 SGLT-2, if appropriate; Also, Add Met +GLP-1 one of the drugs on right: Met + AGI Met + SU/glinide Met +Pre-meal rapid-acting insulin TZD + Basal insulin Increase dose of TZD,if Met + DPP-4 appropriate; Also, Add one of the Met + GLP-1 drugs onright: Met + SGLT-2 Met + AGI Met + SU/glinide Met + Pre-mealrapid-acting insulin DPP-4 + SGLT-2 Increase dose of DPP-4 and/or Met +AGI SGLT-2, if appropriate; Also, Add Met + SU/glinide one of the drugson right: Met + Pre-meal rapid-acting insulin GLP-1 + SGLT-2 Increasedose of GLP-1 and/or Met + AGI SGLT-2, if appropriate; Also, Add Met +SU/glinide one of the drugs on right: Met + Pre-meal rapid-actinginsulin Basal insulin + Increase dose of SGLT-2 if Met + DPP-4 SGLT-2appropriate; Also, Add one of the Met + GLP-1 drugs on right: Met + AGIMet + SU/glinide Met + Pre-meal rapid-acting insulin

Still referring to FIG. 13 , after determining the recommendedmodifications to the patient's current therapy configuration, therecommendation process 1300 generates or otherwise provides graphicalindicia of the recommended therapy changes in graphical association withthe identified event pattern (task 1312). In one or more embodiments,the server 206 generates recommended therapy modifications whenpopulating the event pattern analysis region associated with theidentified event, for example, by displaying recommended therapymodifications for the highest priority event pattern in its associatedevent pattern analysis region of the pattern guidance display. Inanother embodiment, the server 206 generates or otherwise provides therecommended therapy modifications in response to selection of aparticular event pattern for analysis (e.g., from within the eventpattern analysis region). In various embodiments, the graphical indiciaof a recommended therapy modification may be realized as a graphicalrepresentation or depiction of text stored in the database 208 (e.g., inassociation with the therapy modification logic rules, in associationthe therapy configuration for which the recommended therapy modificationis an option, or the like).

FIG. 14 depicts an exemplary embodiment of a snapshot GUI display 1400(or report) that may be presented on a display device associated with anelectronic device, such as the client device 210, in connection with therecommendation process 1300 of FIG. 13 . Similar to the snapshot GUIdisplay 100 of FIG. 1 , the snapshot GUI display 1400 includes a patterndetection region 1406 including a plurality of pattern guidance displays1420, 1430, 1440 corresponding to patterns of events identified duringthe snapshot time period based on the patient's sensor glucosemeasurement values for the snapshot time period. In the illustratedembodiment of FIG. 14 , the highest prioritized detected event pattern,a variability event associated with the overnight time period, isidentified by the recommendation process 1300 for recommending therapymodifications capable of addressing the overnight variability eventgiven the patient's current therapy.

As described above in the context of FIG. 13 , the server 206 accessesthe database 208 using the patient's identification information toidentify the current therapy configuration for the patient (500milligrams of metformin twice daily and basal insulin in the evening)and obtain the therapy modification logic rules associated with the dualcombination therapy of metformin and basal insulin. In exemplaryembodiments, the obtained therapy modification logic rules alsocorrespond to the patient's estimated A1C level for the snapshot timeperiod. For example, there may be one set of variability event therapymodification logic rules for the metformin and basal insulin dualtherapy combination associated with A1C levels below a threshold valueof 9% and another set of variability event therapy modification logicrules for the metformin and basal insulin dual therapy combinationassociated with A1C levels above the threshold value of 9%, with theserver 206 selecting the therapy modification logic rules associatedwith A1C levels below the threshold value based on the patient'sestimated A1C level for the snapshot time period of 5.7%.

Based on the obtained therapy modification rules and the patient'scurrent dosages, the server 206 identifies a recommended therapymodification of reducing the basal insulin dosage to address theovernight variability event. In this regard, the server 206 may identifya modification to the dosage or delivery rate of insulin to be deliveredby the infusion device 202 during future instances of the monitoringperiod associated with the highest prioritized detected event pattern(e.g., the basal dosage during the overnight time period). Thereafter,one or more autonomous operating modes supported by the infusion device202 may be modified, adjusted, or otherwise reconfigured to autonomouslyregulate the condition of the patient in accordance with the recommendeddosage modification in response to a user input. For example, thepatient or other user (e.g., the patient's doctor or another clinician)could then interact with the infusion device 202 (e.g., by manipulatinguser interface 1040) to reprogram or reconfigure one or more parameters,limits, targets, set points, or other settings associated with thecontrol scheme or algorithm implemented by the infusion device 202 toachieve the modified dosage when autonomously regulating the patient'sglucose level during the time of day corresponding to the monitoringperiod associated with the detected event pattern (e.g., duringovernight closed-loop operation). To reduce the evening basal insulindosage by 10% to 20% as indicated in analysis region 1426, the overnightbasal infusion rate setting of the infusion device 202 may be reduced bythe corresponding percentage, or the amount of insulin injected atbedtime may be reduced by the corresponding percentage.

In some embodiments, the graphical representation of a modification tothe dosage or delivery rate of insulin to be delivered by the infusiondevice 202 during future instances of the monitoring period may beselectable or associated with a button or similar selectable GUI elementthat facilitates the client device 210 or the server 206 automaticallyreprogramming the infusion device 202 (e.g., by transmittingcorresponding commands, code or other programming instructions to theinfusion device 202 via the network 214) for implementing the modifieddosage during the relevant time period. Additionally, in the illustratedembodiment, the server 206 utilizes the obtained therapy modificationrules to identify another recommended therapeutic remedial action ofadding a bedtime snack to increase the patient's glucose level. In thisregard, in some embodiments, a recommended therapeutic remedial actionmay be identified based on the patient exhibiting sensor glucosemeasurement values above or below a threshold (e.g., below the lowerglucose threshold value for the overnight monitoring time periodassociated with the highest priority variability event) and/or aduration of time during which those measurements are exhibited withinthe monitoring period.

In a similar manner as described above in the context of FIGS. 1-4 , theserver 206 generates a header region 1422 with graphical indicia of theovernight variability event. In connection with the recommendationprocess 1300, the server 206 generates a current therapy summary region1424 that includes graphical indicia of the patient's current therapyconfiguration along with an analysis region 1426 that includes graphicalindicia of the recommended remedial actions identified based on therapymodification rules associated with the patient's current therapyconfiguration. In some embodiments, the therapy summary and analysisregions 1424, 1426 are presented in response to user selection of theovernight variability event pattern guidance display 1420 or the headerregion 1422 in lieu of other summary and analysis regions (e.g., regions124, 126). In this regard, the recommendation process 1300 may betriggered or initiated to generate and populate the therapy summary andanalysis regions 1424, 1426 presented in response to user selection ofthe overnight variability event pattern guidance display 1420 or theheader region 1422. In other embodiments, therapy summary and analysisregions 1424, 1426 may automatically be presented for the highestpriority event pattern in lieu of other summary and analysis regions(e.g., regions 124, 126) upon initial generation of the snapshot GUIdisplay 1400.

Although not illustrated in FIG. 14 , in various alternativeembodiments, the recommendation process 1300 may be automaticallyperformed with respect to the other displayed event patterns to populatethe remaining pattern guidance displays 1430, 1440 in addition topattern guidance display 1420. Alternatively, the recommendation process1300 may be performed with respect to one of the other displayed eventpatterns in response to selection of the respective pattern guidancedisplay 1430, 1440. However, as noted above, remedial actions that maybe taken to mitigate or otherwise address lower priority event patterncould be redundant, unnecessary, and/or confusing in view of recommendedremedial actions for the highest priority event pattern.

FIG. 15 depicts another exemplary embodiment of a snapshot GUI display1500 that may be presented on or by an electronic device in connectionwith the recommendation process 1300 of FIG. 13 . The snapshot GUIdisplay 1500 includes a patient therapy region 1510 that includesgraphical indicia of the patient's current therapy configuration, whichcould be rendered outside of or alongside of the pattern detectionregion. In the embodiment of FIG. 15 , the event pattern analysis region1526 of the highest priority pattern guidance display 1520 includesgraphical indicia of the recommended therapeutic remedial actions 1528identified by the recommendation process 1300 while the current patienttherapy configuration is concurrently presented within the patienttherapy region 1510. In one or more embodiments, the recommendedtherapeutic remedial actions 1528 are prioritized or ordered first amongthe information presented within the event pattern analysis region 1526,for example, by displaying the recommended therapeutic remedial actions1528 above the potential causes or other information related to theovernight variability event pattern.

FIG. 16 depicts another exemplary embodiment of a snapshot GUI display1600 that may be presented on or by an electronic device in connectionwith the recommendation process 1300 of FIG. 13 . The snapshot GUIdisplay 1600 includes a patient therapy region 1610 that includesgraphical indicia of the patient's current therapy configuration whichis displayed proximate the pattern detection region 1606. In theembodiment of FIG. 16 , the pattern detection region 1606 includes amenu or list of pattern guidance displays 1620, 1630, 1640 ranked orordered according to prioritization, with graphical indicia of therecommended therapeutic remedial actions 1628 being presented below thehighest priority event pattern guidance display 1620 in graphicalassociation with or proximity to the highest priority event pattern. Inthis regard, in some embodiments, the pattern guidance displays 1620,1630, 1640 may be expandable or collapsible to display recommendedtherapeutic remedial actions in response to user selection of respectiveones of the pattern guidance displays 1620, 1630, 1640. In suchembodiments, the recommendation process 1300 may be initiated orotherwise performed with respect to a selected event pattern todetermine recommended therapeutic remedial actions for populating theexpanded pattern guidance display region upon or in response to userselection of the respective event pattern.

The snapshot GUI display 1600 also includes a supplemental informationregion 1650 that may include disclaimer language or other explanatoryinformation or guidance pertaining to the recommended therapeuticremedial actions 1628, such as, for example, potential side effectsassociated with proposed medications to be added to the patient'stherapy regimen, or the like. The supplemental information region 1650may be displayed adjacent to or otherwise in graphical association withthe pattern detection region 1606 or the selected pattern guidancedisplay 1620. Information presented in the supplemental informationregion 1650 may be stored or maintained in the database 208 andretrieved by the server 206 for presentation. In other embodiments,rules or formula for generating the supplemental information may bestored or maintained in the database 208 and retrieved by the server 206for dynamically determining the supplemental information to be presentedin the region 1650 based on the patient's current therapy configuration,physiological condition, or other patient-specific variables or factors.

It should be noted that FIGS. 14-16 depict merely some exemplary GUIdisplays for presenting recommended therapeutic remedial actions, andthe subject matter described herein is not necessarily limited to anyparticular manner of presentation. By virtue of the recommendationprocess 1300 of FIG. 13 , detected event patterns exhibited by aparticular patient and that patient's particular therapy configuration,physiological condition, and potentially other patient-specificvariables may be synthesized and analyzed to determine comprehensivetherapeutic recommendations for remedying, resolving, mitigating, orotherwise addressing a particular event pattern in a manner thataccounts for the patient's current therapy and physiological condition.The recommended therapeutic remedial actions may also account forvarious patient-specific variables to provide recommendations thatreflect a relatively comprehensive review of the patient's medicalrecords, history and prior therapies. The recommended therapeuticremedial actions are then presented in connection with other graphicalindicia pertaining to detected event pattern, thereby clearly conveyingto the patient or other user the nature of the event pattern andpotential ways to address the event pattern, which, in turn, leads tobetter patient outcomes.

It should be noted that although the subject matter may be describedherein primarily in the context of a patient with Type 2 diabetes takingany one of a wide variety of medications (orals, non-insulininjectables, and insulin) in connection with an infusion device orcontinuous glucose monitoring, the subject matter described herein isnot necessarily limited to use with infusion devices, continuous glucosemonitoring, Type 2 diabetes, or the medications described herein.Moreover, in exemplary embodiments, the recommendation processesdescribed herein support modularity or adaptability to accommodatepotential new classes of medications and/or new indications for existingclasses of medications. For example, the therapeutic modification logicrules may have a modular design that allows for a new module of logicrules pertaining to a new class of medication to be inserted orotherwise configured among logic rules pertaining to existing classes ofmedications, thereby allowing the therapeutic modification logic rulesto be readily updated to accommodate new classes of medication.Similarly, indications for existing classes of medications may bemodular, allowing for changes with respect to the indications for thoseclasses or medications that do not impact other classes or medicationsor the overall hierarchy or flow associated with the therapeuticmodification logic rules. Such modularity of the therapeuticmodification logic rules facilitates inclusion and prioritization of newclasses of medication and/or new indications for existing classeswithout substantial redesign of the recommendation algorithms orhardware.

Streamlined Snapshot Displays Including Detected Event Patterns withTherapeutic Recommendations

Referring now to FIGS. 17-20 , in one or more exemplary embodiments, astreamlined snapshot GUI display is provided to convey patientinformation pertaining to past operation of a fluid infusion device orother monitoring device (e.g., a continuous glucose monitor) withimproved clarity, discriminability and consistency, and therebyimproving comprehensibility of the snapshot GUI display. In this regard,regions with relatively higher visual consistency and/or relatively lesscontent variability on a patient-to-patient basis, such as the headerand graph overlay regions, are visually prioritized over regions wherethe displayed information is more likely to vary frompatient-to-patient, such as the pattern detection region, the patienttherapy region, and/or other supplemental information regions. Thisimproves detectability of important information within the visuallyprioritized regions, such as, for example, the patient's current therapyregimen or the patient's historical measurement data for the patient'sglucose level over the snapshot time period that provides the foundationor underlying basis for information presented in the other regions ofthe display. Additionally, detected event patterns are presented in atop-down manner according to prioritization, thereby improving thedetectability and discriminability of the higher priority eventpattern(s). The detected event pattern regions are also capable ofdynamically increasing or decreasing the amount of displayed informationassociated with a respective event pattern, thereby improvingconciseness of the overall display, while also potentially allowing forimproved legibility by increasing available display area for otherinformation.

Referring to FIG. 17 , similar to the snapshot GUI display 100 describedabove in the context of FIGS. 1-4 , the streamlined snapshot GUI display1700 includes a patient information header region 1702 presented at thetop of the snapshot GUI display 1700 above a performance metric region1704. In the streamlined snapshot GUI display 1700, a graph overlayregion 1708 closer to the top of the snapshot GUI display 1700 above anevent pattern detection region 1706.

In the illustrated embodiment, similar to the performance metric region104 in FIG. 1 , the performance metric region 1704 includes graphicalrepresentations or other indicia of the values for various performancemetrics summarizing the patient's condition over the snapshot timeperiod that are calculated based on the historical measurement data forthe patient's glucose level over the time period associated with thesnapshot GUI display 1700. Additionally, the performance metric region1704 includes graphical representations 1710 (or other graphicalindicia) of the patient's current therapy regimen. In this regard, thedisplayed therapy regimen information 1710 includes a listing of themedications or other medicaments the patient is currently taking. In theillustrated embodiment, the current patient therapy information 1710indicates the patient administers basal insulin injections in theevening and also administers meal-time insulin.

As depicted in FIGS. 18-19 , for other types of medications ormedicaments, for each medication or medicament, the displayed therapyregimen information includes the frequency at which the respectivemedication or medicament is administered or taken by the patient (e.g.,daily, twice a day (BID), three times a day (TID), four times a day(QID), etc.) along with a dosage associated with each instance, and fora medication or medicament taken at an uncommon time, an indication ofthe time when taken (e.g., morning (AM), evening (PM), breakfast, lunch,dinner, bedtime, etc.). In exemplary embodiments, the brand name isbolded or otherwise visually emphasized, while the generic name, dosage,frequency, or other temporal indicia are not emphasized. For example, if850 milligrams of GLUCOPHAGE® is taken twice a day at breakfast anddinner, the corresponding listing in the displayed therapy regimeninformation may be displayed as “Glucophage (metformin), 850 mg BID.”Alternatively, if 850 milligrams of GLUCOPHAGE® is taken twice a day atbreakfast and lunch, which is not a commonly expected time for a dose,the corresponding the displayed therapy regimen information may bedisplayed as “Glucophage (metformin), 850 mg BID, breakfast and lunch.”

Still referring to FIG. 17 , the graph overlay region 1708 is displayedimmediately below and adjacent to the performance metric region 1704 andabove the event pattern detection region 1706. This arrangement isconsistent with the order in which the patient's doctor or otherclinician is likely to be interested in reviewing the patient's history,and thereby improves clarity of the snapshot GUI display 1700 anddetectability of the graph overlay region 1708 by directing the viewer'seyes towards the graph overlay region 1708 via preferential placementabove the event pattern detection region 1706. This improves theperceived flow of the snapshot GUI display 1700 while also improvingcomprehensibility of the information subsequently presented in the eventpattern detection region 1706 by conveying the relevant underlyinghistorical measurement data for the patient to the viewer first.Additionally, since the general look and feel of the graph overlayregion 1708 is independent of the patient's physiological condition(e.g., whether or not the patient has type 1 diabetes or type 2diabetes), the perceived consistency of the snapshot GUI display 1700across a patient population is improved.

Similar to the graph overlay region 108 of FIG. 1 , the graph overlayregion 1708 includes graphical representations of historical measurementdata for the patient's glucose level over the snapshot time period withrespect to time and a visually distinguishable overlay region thatindicates a personalized target range for the patient's sensor glucosemeasurement values, with the graphical representation of themeasurements, meal markers, or other indicia for each different day ordate depicted on the graph overlay region 1708 being rendered visuallydistinct from graphical representations corresponding to other days ordates. The illustrated graph overlay region 1708 also includes graphicalrepresentations of multiday averages of the measurement data fordifferent periods or times of day, for example, every three-hour segmentof the day. The graph overlay region 1708 also includes graphicalindicia 1728, 1738, 1748 of highest priority detected event patterns ina manner that establishes an association between the detected eventpattern, the time of day associated with its corresponding monitoringperiod, and its relative priority level.

The event pattern detection region 1706 is presented below the graphoverlay region 1708 and includes a plurality of pattern guidancedisplays 1720, 1730, 1740 corresponding to the three highest prioritizedevent patterns identified during the snapshot time period based on thepatient's sensor glucose measurement values for the snapshot timeperiod. The pattern guidance displays 1720, 1730, 1740 are expandable orcollapsible to dynamically increase or decrease the amount ofinformation presented in association with a respective event pattern. Inthe embodiment of FIG. 17 , the second and third priority event patternguidance displays 1730, 1740 are collapsed or not expanded, while thehighest priority event pattern guidance display 1720 is expanded todisplay an event pattern analysis region 1724 associated with the eventpattern and a therapy analysis region 1726 for the event pattern withina window 1721 associated with the header region 1722 for the highestpriority event pattern guidance display 1720. The event pattern analysisregion 1724 includes list of potential causes phrased in a manner thatsuggests remedial actions that can be taken to resolve or correct thevariability event, while the therapy analysis region 1726 includesrecommended therapeutic remedial actions for resolving or correcting thevariability event. The list of potential causes may be personalized orotherwise tailored for the medications or classes of medicationscorresponding to the patient's current therapy regimen (e.g., a possiblecause related to insulin will not be displayed if the patient is nottaking insulin). The contents of the analysis regions 1724, 1726 may beidentified, determined, or otherwise generated as described above in thecontext of FIGS. 1-4 and FIGS. 13-16 .

The header regions 1722, 1732, 1742 for each of the pattern guidancedisplays 1720, 1730, 1740 includes a number indicating the priority ofthe respective event pattern, an identification of the type of eventpattern detected, and the time period or timeframe associated with thedetected event pattern. In exemplary embodiments, the header regions1722, 1732, 1742 are selectable or otherwise manipulable to dynamicallyincrease or decrease the displayed information associated with therespective event pattern. In this regard, FIG. 17 depicts an examplewhere the highest priority event header region 1722 has been selected orotherwise activated to expand the window 1721 associated with thehighest priority event below the highest priority event header region1722 to display the analysis regions 1724, 1726 associated with thehighest priority event above the lower priority event pattern guidancedisplays 1730, 1740 (e.g., between the highest priority event headerregion 1722 and the second highest priority event header region 1732),while the other header regions 1732, 1742 are in their deselected ordeactivated states to remove or otherwise hide the analysis regionsassociated with the lower priority event pattern guidance displays 1730,1740. In some embodiments, the markers 1728, 1738, 1748 corresponding tothe respective pattern guidance displays 1720, 1730, 1740 may also beselectable or otherwise manipulable to dynamically increase or decreasethe displayed information associated with the respective event pattern.For example, to expand the highest priority event pattern guidancewindow 1721, a user may select either the highest priority event headerregion 1722 or the highest priority event marker 1728 within the graphoverlay region 1708. Additionally, in some embodiments, the highestpriority event pattern guidance display 1720 may be automaticallyactivated or expanded by default (and the lower priority event patternguidance displays 1730, 1740 collapsed or condensed by default) uponpresentation of the snapshot GUI display 1700 even in the absence of anyuser selection.

By allowing event pattern information to be selectively and dynamicallyhidden or added to the display, the perceived clarity and conciseness ofthe event pattern detection region 1706 is improved, which, in turn mayhelp aid the comprehensibility of the displayed information.Additionally, freeing up display area on the display device by hidinginformation associated with lower priority event pattern guidancedisplays 1730, 1740 may allow for the legibility of the displayedinformation associated with the higher priority event pattern guidancedisplay 1720 to be improved by increasing the size of the text, icons,or other graphical elements that make up the analysis regions 1724, 1726to fill the available display area.

In exemplary embodiments, the event pattern markers 1728, 1738, 1748 andheader regions 1722, 1732, 1742 utilize different colors thatdifferentiate one another and indicate whether a detected event patterninvolves a low or high glucose level. For example, the marker 1728associated with the low glucose variability event may be rendered usingred, pink, or a similar hue to indicate a relatively higher potentialseverity associated with the event, and similarly, at least a portion ofthe header region 1722 may be rendered using the same color (e.g., theportion 1723 of the header region 1722 encompassing the identificationof the event type and priority). Such color-coordination conveys orotherwise implies the importance and severity of the event patternconsistent with society and reduces the amount of time required for auser to identify the most significant event patterns on the graphoverlay region 1708. Conversely, markers 1738, 1748 and header regions1732, 1742 associated with a high glucose level may incorporate yellowor a similar hue to indicate a relatively lower severity.

FIG. 18 depicts another exemplary embodiment of a streamlined snapshotGUI display 1800. In the embodiment of FIG. 18 , the expanded window1821 for the highest priority event pattern guidance display 1820 in theevent pattern detection region 1806 below the graph overlay region 1808includes a tabular representation 1828 of recommended therapeuticremedial actions within the therapy analysis region 1826 for resolvingor correcting the low glucose event. In this regard, the table 1828 ofrecommended therapeutic remedial actions indicates a plurality ofdifferent potential therapeutic remedial actions that may be appropriatefor the patient's current therapy regimen. The different potentialtherapeutic remedial actions are differentiated by a visuallydistinguishable vertical divider 1825 into a first subset 1827 ofpotential remedial actions for a symptomatic patient and a second subset1829 of potential remedial actions if the patient is asymptomatic. Inthe illustrated embodiment, the tabular therapy analysis region 1826 ispresented within the expanded window 1821 associated with the highestpriority event pattern header region 1822 beneath the event patternanalysis region 1824 and above the header regions and guidance displaysfor the lower priority event patterns.

As described above in the context of FIG. 13 , the potential therapeuticremedial actions presented in the various columns of the table 1828 aredetermined for the corresponding event pattern based on the patient'scurrent therapy configuration. Each column of the table 1828 is uniquerelative to other columns in the table 1828, and each column includesone or more potential therapeutic remedial actions, such as, forexample, a modified dosage (or cessation) of a current medication ormedicament, an additional medication or medicament, and/or a combinationthereof. The table 1828 of potential therapeutic modifications allowsthe patient's doctor or clinician to readily identify a broad set ofpotential therapy modifications that may be appropriate given thepatient's current therapy configuration and physiological condition,from which the patient's doctor or clinician can then utilize his or herprofessional judgment to determine how to modify the patient's therapyto achieve an optimal outcome.

FIG. 19 depicts another exemplary embodiment of a streamlined snapshotGUI display 1900 where each of the event pattern guidance displays 1920,1930, 1940 within the event pattern detection region 1906 beneath thegraph overlay region 1908 are expanded. In such an embodiment, theamount of information presented within the respective pattern guidancedisplays 1920, 1930, 1940 may be reduced to maintain legibility, forexample, by limiting the number of potential causes presented within therespective pattern analysis regions, limiting the number of recommendedtherapeutic remedial actions within the respective therapy analysisregions, or a combination thereof. In the illustrated embodiment, thepattern guidance displays 1920, 1930, 1940 only include pattern analysisregions associated with the respective event patterns. In this regard,the respective therapy analysis regions may be hidden or otherwiseremoved from the display to increase the available display area forexpanding multiple pattern guidance displays, while also improvingclarity by decluttering the display and eliminating potential confusionthat could arise by presenting a number of recommended therapeuticremedial actions attempting to individually resolve different eventpatterns, which could potentially conflict with one another orexacerbate another aspect of the patient's physiological condition.Thus, in such scenarios where the patient's doctor or clinician isconcurrently considering or reviewing multiple different event patterns,the patient's doctor or clinician can use his or her judgment indetermining how to modify the patient's therapy to achieve an optimaloutcome.

FIG. 20 depicts an embodiment of a streamlined snapshot GUI display 2000that does not include recommended therapeutic remedial actions due tothe absence of information regarding any medications or medicamentsprescribed for the patient. In such scenarios, an informational region2010 is provided vertically between the graph overlay region 2008 andthe event pattern detection region 2006 to convey to the viewer or userof the snapshot GUI display 2000 that the following event patterndetection region 2006 does not include therapy analysis regions orrecommended therapeutic remedial actions and the underlying rationalefor why that information is not presented. The informational region 2010mitigates potentially perceived inconsistencies in the streamlinedsnapshot GUI display 2000 across different patients by indicating,explaining, or otherwise conveying a potential inconsistency within thefollowing region 2006 of the display 2000 prior to the eyes of a viewerreading the display 2000 in a top-down fashion reaching the followingregion 2006. In other words, the informational region 2010 effectivelymodifies a viewer's expectations regarding the content of thestreamlined snapshot GUI display 2000 to align with what is subsequentlypresented beneath the region 2010, which improves the perceivedconsistency of the streamlined snapshot GUI display 2000.

In sum, the streamlined snapshot GUI displays provided in FIGS. 17-20achieve improved conformance with user expectations and direct userstowards information in a manner that may be perceived as logical andpredictable. Color-coordination between the graph overlay regions andevent pattern detection regions and top-down prioritization of eventpattern guidance allow users to quickly and accurately distinguishimportant event patterns, and the amount of displayed event patterninformation may be dynamically increased or decreased to improveconciseness and legibility. As a result, the interpretability andcomprehensibility of the snapshot GUI display is improved, which, inturn results in increased confidence in the presented information. Thus,the streamlined snapshot GUI displays increase the likelihood ofimproved patient outcomes resulting from increased reliance onrecommended therapeutic remedial actions and/or other guidance oranalysis presented on the displays.

For the sake of brevity, conventional techniques related to glucosesensing and/or monitoring, bolusing, meal boluses or correction boluses,and other functional aspects of the subject matter may not be describedin detail herein. In addition, certain terminology may also be used inthe herein for the purpose of reference only, and thus is not intendedto be limiting. For example, terms such as “first”, “second”, and othersuch numerical terms referring to structures do not imply a sequence ororder unless clearly indicated by the context. The foregoing descriptionmay also refer to elements or nodes or features being “connected” or“coupled” together. As used herein, unless expressly stated otherwise,“coupled” means that one element/node/feature is directly or indirectlyjoined to (or directly or indirectly communicates with) anotherelement/node/feature, and not necessarily mechanically.

While at least one exemplary embodiment has been presented in theforegoing detailed description, it should be appreciated that a vastnumber of variations exist. It should also be appreciated that theexemplary embodiment or embodiments described herein are not intended tolimit the scope, applicability, or configuration of the claimed subjectmatter in any way. For example, the subject matter described herein isnot necessarily limited to the infusion devices and related systemsdescribed herein. Moreover, the foregoing detailed description willprovide those skilled in the art with a convenient road map forimplementing the described embodiment or embodiments. It should beunderstood that various changes can be made in the function andarrangement of elements without departing from the scope defined by theclaims, which includes known equivalents and foreseeable equivalents atthe time of filing this patent application. Accordingly, details of theexemplary embodiments or other limitations described above should not beread into the claims absent a clear intention to the contrary.

What is claimed is:
 1. A system, comprising: one or more processors; andone or more processor-readable media storing instructions which, whenexecuted by the one or more processors, cause performance of:identifying a plurality of event patterns within a plurality ofmonitoring periods based on measurement values of a physiologicalcondition; causing display of a snapshot graphical user interfacedisplay, wherein: the snapshot graphical user interface displaycomprises a graph overlay region and an event detection region, thegraph overlay region comprises a graphical representation of themeasurement values with respect to a time of day, and the eventdetection region comprises a pattern guidance display for at least asubset of the plurality of event patterns, wherein the pattern guidancedisplay for at least one event pattern of the subset of the plurality ofevent patterns includes a graphical representation of a recommendedtherapeutic remedial action that comprises therapy parameters, to beused by a medical device during a subsequent time period, configured tomitigate occurrence of the at least one event pattern during thesubsequent time period; and causing, responsive to user input, automatedreprogramming of the medical device for implementation of therecommended therapeutic remedial action prior to the subsequent timeperiod.
 2. The system of claim 1, wherein the user input comprisesselection of the graphical representation of the recommended therapeuticremedial action.
 3. The system of claim 1, wherein the at least oneevent pattern indicates that a glucose level is outside a target glucoserange during a time period associated with the at least one eventpattern.
 4. The system of claim 3, wherein the therapy parameters definea change in an amount of insulin to deliver and a time at which todeliver the amount of insulin prior to the subsequent time periodassociated with the at least one event pattern to mitigate occurrence ofthe glucose level being outside the target glucose range during thesubsequent time period.
 5. The system of claim 1, wherein the medicaldevice comprises an infusion device that is operable to deliver fluid toa body of a patient associated with the medical device.
 6. The system ofclaim 1, wherein the instructions further cause performance ofprioritizing the plurality of event patterns to generate a prioritizedlist.
 7. The system of claim 6, wherein the instructions further causefiltering of the prioritized list of the plurality of event patternsbased on one or more filtering criteria.
 8. The system of claim 7,wherein the pattern guidance display presents the subset of theplurality of event patterns based at least in part on the filteredprioritized list.
 9. The system of claim 7, wherein the recommendedtherapeutic remedial action is one of one or more recommendedtherapeutic remedial actions, and wherein the pattern guidance displayfor a highest priority event pattern of the filtered prioritized listincludes a pattern analysis region identifying one or more potentialcauses of the highest priority event pattern above a therapy analysisregion identifying the one or more recommended therapeutic remedialactions pertaining to the highest priority event pattern.
 10. The systemof claim 9, wherein the therapy analysis region comprises a tableincluding a plurality of columns, and wherein each column of theplurality of columns corresponds to a respective recommended therapeuticremedial action of the one or more recommended therapeutic remedialactions.
 11. The system of claim 10, further comprising a database tostore therapeutic modification logic rules associated with the highestpriority event pattern, wherein the one or more processors arecommunicatively coupled to the database to obtain the therapeuticmodification logic rules from the database, identify a current therapyfor a patient, and identify the one or more recommended therapeuticremedial actions based at least in part on the therapeutic modificationlogic rules and the current therapy, and wherein the recommendedtherapeutic remedial action of the pattern guidance display is one ofthe identified one or more recommended therapeutic remedial actions. 12.The system of claim 9, wherein the therapy analysis region is hidden inresponse to expansion of the respective pattern guidance display foranother event pattern of the filtered prioritized list.
 13. The systemof claim 1, wherein the pattern guidance display for each event patternof the subset of the plurality of event patterns is expandable orcollapsible.
 14. The system of claim 1, wherein the graph overlay regionincludes a marker associated with each event pattern of the subset ofthe plurality of event patterns, wherein each marker encompasses aperiod of time corresponding to the event pattern associated therewith.15. The system of claim 14, wherein the pattern guidance display foreach event pattern includes a respective header region that iscolor-coordinated with the marker associated with the respective eventpattern.
 16. The system of claim 1, further comprising a database tostore the measurement values, wherein the instructions further causeperformance of obtaining the measurement values from the database andidentifying the plurality of event patterns based on the obtainedmeasurement values.
 17. The system of claim 1, wherein the instructionscause display of the snapshot graphical user interface display to aclient computing device communicatively coupled to the one or moreprocessors, the client computing device displaying the snapshotgraphical user display on a display device associated therewith.
 18. Thesystem of claim 1, wherein the one or more measurement values areobtained from a continuous glucose monitoring (CGM) device.
 19. Aprocessor-implemented method comprising: identifying a plurality ofevent patterns within a plurality of monitoring periods based onmeasurement values of a physiological condition; causing display of asnapshot graphical user interface display, wherein: the snapshotgraphical user interface display comprises a graph overlay region and anevent detection region, the graph overlay region comprises a graphicalrepresentation of the measurement values with respect to a time of day,and the event detection region comprises a pattern guidance display forat least a subset of the plurality of event patterns, wherein thepattern guidance display for at least one event pattern of the subset ofthe plurality of event patterns includes a graphical representation of arecommended therapeutic remedial action that comprises therapyparameters, to be used by a medical device during a subsequent timeperiod, configured to mitigate occurrence of the at least one eventpattern during the subsequent time period; and causing, responsive touser input, automated reprogramming of the medical device forimplementation of the recommended therapeutic remedial action prior tothe subsequent time period.
 20. One or more processor-readable mediastoring instructions which, when executed by one or more processors,cause performance of: identifying a plurality of event patterns within aplurality of monitoring periods based on measurement values of aphysiological condition; causing display of a snapshot graphical userinterface display, wherein: the snapshot graphical user interfacedisplay comprises a graph overlay region and an event detection region,the graph overlay region comprises a graphical representation of themeasurement values with respect to a time of day, and the eventdetection region comprises a pattern guidance display for at least asubset of the plurality of event patterns, wherein the pattern guidancedisplay for at least one event pattern of the subset of the plurality ofevent patterns includes a graphical representation of a recommendedtherapeutic remedial action that comprises therapy parameters, to beused by a medical device during a subsequent time period, configured tomitigate occurrence of the at least one event pattern during thesubsequent time period; and causing, responsive to user input, automatedreprogramming of the medical device for implementation of therecommended therapeutic remedial action prior to the subsequent timeperiod.